I find myself working as a project manager, or a program management consultant more frequently in the last few years. As would be expected by those reading the Curious Cat Management Improvement blog, my project management views are based on the management improvement principles I have discussed here for over 20 years.
This post is in the style of my Good Process Improvement Practices and Practical Ways to Respect People posts.
Good project management practices include
- Deliver a working solution quickly; add value as you have time. Don’t aim to deliver a final product by the deadline and risk missing the deadline. Deliver a good solution early, adjust based on feedback and add more as you have time.
- Prioritize – do fewer things, and do them well.
- Limit work in process (WIP) – finish tasks, avoid the problems created by splitting attention across numerous tasks.
- Consider the long term from the start – build solutions that allow iteration and continual improvement. An initially very good solution that is difficult to adapt as desires change is not a good solution.
- Grow the capability of the organization while making progress on projects.
- Use data wisely (data can be extremely valuable and should be used much more, but it must be used with a critical eye).
- Use retrospectives during the project and at the end of the project to continually improve the process of managing the project (and the capability of the organization to manage projects overall).
- Practice respect for people
- Coach people on good management improvement practices as those opportunities present themselves as the project moves forward. This will let them be more effective on the project and also build the capability of the organization for the long term. Don’t just “trust” people to succeed without giving them the proper training, coaching and authority.
- Select the right people for the project – the decision makers and those working on the project need to include those most knowledgeable about end users for the what the project will deliver. Those involved also need to have the right knowledge, personality, skill and roles in the organization.
- Multiple smaller projects are often better than a large project that is difficult to manage and coordinate communication for.
- Kanban is a useful strategy to reduce work in progress. Trello is a useful tool to manage tasks.
- As a project manager focus on making the entire process effective (not on doing tasks yourself). Make sure others are limiting work in progress. Working solutions should be delivered quickly; if that requires thinking how to scope such working solutions – take the time to do that. Make sure people are interacting with end users as soon as possible and adjusting based on what they learn. Make sure the solutions under development are built with continual improvement and iteration in mind (until an organization is used to thinking this way the long term flexibility is often given little focus while deadlines drive people’s effort).
- Communicate frequently with stakeholders (including executives, product owners, those that will be impacted by the project…). Don’t seek to avoid difficult discussions and hope things will magically get better. Let people know the status, emergent risks, etc. and offer alternatives to consider.
- For less important projects seek to greatly minimize the time spent on them by ruthlessly reducing the scope and effort: find a minimal, but acceptable solution. Redirect the saved time to more important projects.
- Seek to delegate responsibility for specific tasks and deliverables to many people. I prefer to delegate directly to more people, and have them seek approval from someone else as needed (say if they are less experienced and you want someone with more experience to review before proceeding). Often instead of this setup a few people have responsibility for nearly everything and others are supposed to help them.
- If you have to disappoint some stakeholders several times (due to the competing priorities) see if you can find ways to deliver something they want without too much effort. When prioritizing, consider as one factor how other decisions have gone. It shouldn’t result in waste or overlooking much more important items but often you can find solutions that will help keep people happy, even though they didn’t get some of the bigger items they wanted.
- In some projects you need to think a bit like a marketer and promote the benefits the project will bring. This is often needed if the project requires a great deal of effort (which could mean significant staff time is redirected to the project) or will require significant changes in some people’s work (which could result in objections).
- If the organization hasn’t established a good management system it may well fall on the project manager to protect those on the project from various aspects of the existing management structure (given extra tasks without considering their existing workload, demands from various parts of the organizations that their part of the project be given priority, being blamed for things unfairly, a supervisor that demanding all their time on other tasks – so they can’t deliver for the project…).
I will add posts to explore some of these items more fully: if you have preferences for which ones I expand on, please let me know.
Each project will be different. Which practices should be emphasized will vary. Which practices that are often wise should be ignored on a specific project will also vary.
Delivering a working solution quickly does a great deal to reduce the risks of failed projects and the value added by successful projects. No one practice alone can make everything succeed, but this practice is extremely powerful. The idea is both to get a solution into user’s hands as quickly as possible (to start getting feedback) and to understand the full process that will need to be completed.
Often organizations spend a great deal of time doing things in sequence completing each step and then moving onto the next (waterfall). This can lead to abandoning projects after a long time with no visible results. Also it can lead to a great deal of wasted effort that could have been avoided if you learned early on that to achieve the final vision some of the initial steps should be approached in a very different way (due to learning the realities imposed by later steps in the process). It is no surprise that delivering working software quickly is a key part of agile software development efforts.
Building enterprise capability is the subtitle of my book (which as you may suspect indicates the importance I place on this practice). This practice doesn’t do much for success of the current project but it is critical to creating an organization that can continually improve the success of projects within the organization.
I am available for management improvement coaching, consulting and distance project management. Contact me if you are interested.
Related: Building a Great Software Development Team – How to Create a Continual Improvement Culture – Internal Management Improvement Experts
People don’t seem to want to do retrospectives if the project turned out well because it turned out well and they don’t think it is needed. They also don’t seem to want to do them if it turned out poorly because of the guilt of poor performance. How do you get people on board for a retrospective no matter the results?
> How do you get people on board for a retrospective no matter the results?
It is very similar to the entire issue of getting people to adopt management improvement practices. Get them on board by showing them how it helps them.
You can get people thinking in the way that continual improvement is are ordinary way of operating by making that point during meetings (mention how we adopted specific change based on feedback…). Talk to people outside meetings about what they want to see improved, how they think things could be improved. Have “mini-retrospectives” within the normal meetings (bring up an item you have discussed with several people, ask a question about how some issue that has appeared several times could be addressed with a system fix…).
Take care to seek visible success in addressing issues people raise. And then build on those successes. If people see things actually get better then they will see retrospectives as a useful way to improve. Without that understanding many will see them as another waste of time. Change that by delivering improvement. The initial improvements are actually most important in bringing about this change in thinking – more than whatever is actually improved.
The link I included earlier goes into that process of changing people’s view of the efforts from a waste of my time into something that can actually improve things for me. The biggest advice is that if your organization has big problems in this area devote more of your time to seeking such visible successes. It will likely take numerous successes to bring a critical mass of people on board.
I would still have the retrospectives each time if possible. But if it really was too difficult and just created more annoyance among people – make it optional. And if no one wanted to do it, just talk to people individually and find out what they want improved and find some way to make some of those improvements happen. Then build on that success.
Stumbled across your article somehow… Your reply here had me , again, frame a question that I ponder consciously from time to time, and in the background, I think, pretty much all the time.
See if I can get it well worded:
So there is this constant call , appeal and implementation for “improvement”. I wonder if things are, on the whole , actually improving, or is there simply change going on. Maybe the improvements are relative to what you’re paying attention to. Or perhaps they are small? Or perhaps the improvements are lost either in part or in whole as the “improving eye” moves on to the next thing?
Of course it is not absolutely no incorporation of various changes… Just that there is a difference, so it seems to me, between Change, and Improvement. One is not the other, necessarily. The question I ask when asked about change is “Change what? To What? Why?”
I suppose this is spawned by the observation that if we were actually improving as we were changing we would not be exhorting the same things over the years as if they still needed to be accomplished.
I wonder if you have a POV on this question/observation?