Now that we have established the differences between Product and Project management, we can look at them from a practical point of view.

Let’s start with Project Management.

Bottom line – if you feel straggle with the subject, then it is time to step back and look at “why” and “what” makes it complex.

It usually comes down to complexity in the project definition, uncertainty of what has to be done, idealistic approach, unclear time-line or simply mismanaging.

To succeed, a project should have clearly defined goals, realistic time-line expectations, proper budget and properly allocated resources. When something goes wrong, it usually falls in the above categories.

Let’s consider the following:

  • Keep the project simple. If you feel that project really includes several standalone parts, then it is time to negotiate a split, properly presenting advantages to project stakeholders.
  • Use tools and practices you are familiar with. Sudden changes in software toolset, ways of getting things done or switching platforms may require double+ time to handle them properly. It’s usually associated with adoption overhead, learning curve, new hardware requirements and other things which are easily not accounted for initially. Yes, there is always a moment when moving from one programming language to another or from one infrastructure model to another is a necessity, but then it should be properly accounted for and handled with more caution.
  • Perfection is your enemy. It is a job of the product management to “dream” about the ideal product which will have everything desired. It should not be an ultimate goal for the project itself. The project may be a step to perfection, but not perfection itself. Therefore, when working on the project, look for efficient ways to achieve project goals while staying within associated timeline and budget. If during this time product might be improved then do it, otherwise, do not make it a reason why project would fail.
  • “Rubber band” or “Iron hammer”. Even though it feels good to have “iron” sturdy methods, you would find more often that it is flexibility which makes a project succeed. This is the main line behind Agile practices, where sudden changes in requirements, time, resources would not, per se, affect target goal. Yes, some renegotiation/planning might be required in the process, but if all parties do understand the reasons and consequences then the target will be reached without big sacrifices and losses.
  • Share the load of knowledge. For you to succeed, everyone on the team should know the project goals, their place in the game and timeline. And you do not achieve that without a significant amount of time allocated to communication – someone has to talk with you, asking questions, sharing ideas, problems and expectations.
  • Talk first, do after. Never assume that everyone is with you about everything in the project – some parts could not be communicated properly (even it might be obvious to you), some parts could be viewed and therefore approached differently (every person has own opinion based on his/her prior experience, and it might be different from yours). It might take 5 minutes to make sure that you will get what you expect, instead of fixing something which did not go in the direction you expected it to.
  • Document your projects and your talks. This is an integral part of communication; people have better understanding of what has to be done when they write it down. During and at the end it will help to look back and see that what was discussed is now implemented… and it will eventually help you documenting your product features, writing end-user documentation, presenting a new product.
  • Let them fly. People, when it comes to creativity have different schedules – some are early birds, others are late night owls. If you are looking for productivity, allow flexibility in the schedule (if business permits). It will pay off and will make the work environment more comfortable. Let people do their job.
  • Track the changes. Change management is, in general, a big topic by itself… Let’s just say that you better know what will be changed, when or what has been changed to properly account for possible impact on the product as a whole. If changes are introduced during the time of project implementation, then they should have a clear placement in the “grand scheme of events” with clear understanding of implications.

Conclusion? Be prepared for challenges, be flexible and be open minded.


Leave a Reply