Pozostałe dobre praktyki PMa

 

In the course of the years I’ve made numerous notes on various aspects of project management. Hope they will come in handy.

Miscellaneous PM Best Practices

  • Have a mission and goal for your project and publish it officially somewhere. It helps not only to motivate (if stated properly) but also to make change management and prioritization decisions.
    • Why do we do this?
    • Who’s waiting for this?
    • What will happen if it is late or the quality is poor?
  • In big projects or programs you could consider hiring dedicated people responsible for jobs such as: research, administration (do you really need to spend one day booking flights for your team?) or communication (do you REALLY know the language, can you write well?).
  • Before you start introducing new methods and ideas – Kanban Boards, Scrum, Lean Coffe, 5 Whys etc., – first make sure you REALLY understand what they are all about, that your knowledge isn’t only based on watching some TED talk. Second – create an environment where those ideas have actual chance to work out. Don’t start remote work experiment without providing necessary tools or don’t experiment with self-organisation with teams who are demotivated and overloaded with work.
  • Make sure you stay up to date with new trends and ideas in management, communications and other relevant areas. Mind the uneasy fact that most of management tools and techniques taught in universities were conceived in times without computers, without internet and instant messaging, for environments where one could reasonably predict the future in 5, or even 10 years perspective. This does not necessarily mean that all of them are completely and inherently wrong. It only means they might (and probably are) far from being perfect and that you should always be looking for ways to improve your manager’s knowledge and toolset.
  • Remember: all models are wrong, but some are useful. E.g. Maslow’s hierarchy of needs is not an universal truth but at the same time its pretty useful as some approximation of how an average Joe prioritises his needs.
  • When managing people and work – don’t over-intervene. Many issues either solve themselves or will be successfully solved by the team – just give them a while. Way too many managers are in a constant ‚hero mode’, proud of themselves and their presumed invaluableness, while in fact they disorganise work in the project and demotivate the team.

Scope management specific best practices:

  • Commit to deliver S.M.A.R.T. objectives rather than requirements. Rather promise to deliver a solution that would bring some business goal, but do not commit how exactly you’d deliver it.
  • ranking requirements helps establishing final scope and making future decisions when cutting it, Use MoSCoW technique for rating your requirements. Moreover, do the same with bugs. Treat them just like a new feature for next iteration. You don’t have to fix them all!
  • Deliver functionality when it’s really necessary Consider the example of the mandatory-life-insurance that’s paid mid-year. First you need sign-up procedures only, later invoicing and payments processing and only one year after maybe some claims processing.
  • Sometimes there might be many product owners In case of complicated projects. One would represent each key user group. Obviously there should still be one that has a final voice, or some other means of decision in case of a conflict.
  • For single iteration plan requirements of different priority This way, once you run into trouble you’ll have easy time cutting the scope.

 

Pytania? Uwagi? Skontaktuj się.