The Danish Computerworld magazine had a few pages on the 14 most common mistakes of project management recently. It is very illuminating to see how agile practices target these mistakes and help avoid them.
1. The project does not have the right people with the right competencies.
While ComputerWorld offers more analysis of skills and workload as a solution, agile practices provide a simple solution: a cross-functional, dedicated team is the basic building block for success.
When this is not possible use the retrospective mechanism to highlight our impediments (e.g.. overburdened key people) and continuously work on improving the situation. For example, I am working with one team that had this exact problem and they made a working agreement that the key people should always pair with the one of the others while doing the work only they can do. This provides a fast-track learning for the others and results in a situation where more team members can help on the resource-constrained tasks, thus reducing the workload on the overburdened key people.
2. The Project Lacks an Experienced Project Manager
The article states that a project can often run off track if there is no experienced project manager at the helm.
You can almost feel the underlying assumption that more management is the solution for all problems.
Scrum has a very radical approach to this, based on a completely different assumption. Eliminate the project manager and give the team the mandate to do what it needs to make the project succeed, then get out of the way.
It is a radical approach - but it works. The key assumption here is that the team disciplined enough to actually follow any practice, but if they are not, no amount of experienced project managers will be able to save the project from trouble. It also relates to the next common mistake:
3. The IT-department Does Not Follow a Standard Project Management Process
You will be be wasting a lot of effort if you don't have an explicit process that people are actually following. And "oops" - it's not enough to have a corporate procedure handbook - only practice counts. Even if people try do do heavy processes and spend a lot of money on training I frequently see that they get very little benefit, since people are still doing what they like if the process is broken. This creates a cognitive dissonance where the training material is focused on one thing - "learn the little red book by heart and be a good party member" and the real world is completely different. It is a situation that is well described in Solzhenitsyn works on the Soviet era where everybody was lying to themselves.
The only way to sidestep the need for process is to have a small group of highly experienced professionals who will follow good practices intuitively without noticing.
For the normal situation, lean offers a better solution:
The take here is to have a simple process, follow it rigorously, and when you master it, continuously work to improve it. This is why we like Scrum so much - it is simple: 3 roles, 3 activities and 3 artifacts, and yet very powerful.
In our training we frame it this way: "Everyone starts with the Scrum, but end up with exactly what they need". That is the whole point - not writing a nice handbook and doing something else, but rather doing a working agreement to work in a certain way, and continuously reflect on these agreements and revise them as needed to fit the situation.
4. The IT-department is Paralyzed by Too Much Progress
The key issue here is keeping to the specification to keep the project on plan (as if!) rather than adding a few new features that the customer might like.
The agile approach here is simple. We never overplan, and we talk intensively with the customer, showing them the real application and getting real-world feedback on where the project needs to go. We even do "Customer Co-Location" and have the customer and team work in the same office to consciously boost this communication and learning cycle.
It is value-driven software development, rather than plan-driven development, thus acknowledging the fact that the plans were done in the beginning of the project when we have very limited knowledge of the business and implementation domain.
As an aside, this is also why I like to speak of "the plan hypothesis", rather than just the Plan since it does not lead to the confusing doublethink that the plan is more real than reality.
5. Changes to the Project Scope are Not Tracked.
The issue is that the budget explodes - and the timeline.
This also reflects an underlying assumption, namely that the project must deliver the initial specification to succeed.
Agile takes another approach. Again, we are back to value-driven development and incremental delivery. By delivering working software frequently - for example, every two weeks, there is no need to track changes to the scope too much since we don't plan more scope than a few weeks ahead. Problems solved by not getting into the bad situation in the first place, rather than putting in a Change Prevention Committee and a big bureaucracy to keep the project in stasis.
6. Missing Up-to-Date Data on the Project Status.
Computerworld gives a one-word advise to remedy this: "Solution: Software."
If you chose to use software at least I would advice to be very careful about what you measure. Earned Value and other methods might look fine, but unless you have a proven track-record in your organisation about being able to use them to RELIABLY PREDICT the delivery of software I would advise to use a simpler metric:
In lean as in agile, we focus on value as defined by the customer: Running, Tested Features working flawlessly in the production environment.
This is a metric that is very simple to track, and hard go game. No more 80% done for many months.
They key agile practices here are Frequent Delivery, Information Radiators like kanban boards with backlogs, burndowns to communicate the current status of the process.
The Japanese call this Mieruka - making information visible so we can act.
7. They Ignore the Problems
In my book this is one of the most frequent problems I meet in large organisations. The "I know it sucks but I am not allowed to fix it", "It's the other department's fault" and all this silo-think.
The lean approach is to map out the entire end to end value creation process and continuously optimize the value delivery flow, not just in one department, but the whole thing.
Key agile practices here are current state analysis to uncover the flow, Retrospectives and other activities as a source for inspiration to Kaizen, the continuous rigorous experimentation with new practices and measuring how they work, one small change at a time so as not to introduce to much variation into the system that might slow down our evaluation of the new practice.
Scrum does this very explicitly by tracking these "Impediments" as on a day-to-day basis combined with a working agreement that the ScrumMaster gives to priority to ensuring that they are removed promptly.
8. They Don't Spend Enough Time to Define The Project Scope
The issue here is that if the project scope is not well defined it will explode.
Agile is very disciplined about this. We take our production capacity as a given and actively manage the scope every sprint. There is even a role for this. The hardest job in Scrum is that of the Product Owner who has to manage all the new ideas and trade-offs every day. It is difficult and is based on the principles of maximizing the value created by constrained set of resources similar to capitalistic entrepreneurship rather than the plan-economy approach of fixed scope as suggested by Computerworld. Come to think of it, next time someone suggests fixed scope on a large timeframe look puzzled and say, "oh, you mean production quotas as they tried in the Soviet Union?"
9. The Dependencies Between Projects are not Visible.
This is a frequent killer in large organisations and the bane of many a SOA implementation. Layers and layers of code from various projects, "The Enterprise Service Bus project", "The Mainframe Project", "The Workflow Project" that all need to coordinate to deliver the end-to-end features.
Computerworld cites an expert who advise to map out the dependencies to better manage them.
Agile advises to eliminate them altogether.
The keys to success here are cross-functional teams that have all necessary competencies to deliver the whole functionality, and, if that is not possible (and remember - "thinking you can't" is one of the biggest wastes), to have all teams integration continuously and track the impediments on a day-to-day basis.
Rather than managing dependencies we aim for just-in-time synchronized delivery by all teams. The key here is solid organisationwide product management, as autonomous, independent teams as possible, frequent delivery, integration and continuous automated testing to make it all spin. It is hard but the alternative is not very attractive, so start going in that direction.
The secret to success is that of Bounded Context - don't try to standardise everything on a corporate-wide basis but let teams do what they need to succeed inside clearly bounded contexts and only spend your effort on managing a limited number of integration points where these Bounded Context need to communicate.
10. They Don't Take Murphy's Law Into Account
The issue here is to mess with the plan meet a deadline set by an external party, like the CEO. Computerworld offers to talk to the CEO about what it takes in terms of time, resources and money to meet the deadline.
Agile calls this Customer Collaboration or engaging the stakeholders in the work to profit maximise the portfolio. The key here is to be honest and transparent and measuring only delivered features, not milestones. Otherwise the Portfolio management will be just like the planning meetings in the Führer bunker where the generals were talking about all their imaginary shadow armies and their victories to please the Führer rather than confronting reality.
I think every project manager should make a decision to never lie, speak against better knowledge or make wildly speculative statements about the future - in fact, the project status reports that I have encountered over the years and their "green-shifting" of bad news to good news as it filters up the chain of command have often indicated that the companies would be better off abolishing these report altogether and measuring status only in terms of what has been delivered without defects into production.
I think the former Avis car rental CEO, Robert Townsend, put it well when he refused to do earnings forecasts saying that, "we don't do in public what we can't do consistently well."
11. They Omit Transformation Management
This mistake is related to build "the next big thing" and forgetting to manage the transformation to make it work in the daily life: simply building nice new software that is not used.
There are various aspects of this, and it is at the heart of the agile practices. Value is measured in customer terms so it is a waste to produce things that are not needed, or to produce software that is needed and not provide the necessary support and training to make it useful in the daily work. This change management process and the resistance to change should not be omitted.
Some of the agile practices in that area are Customer Collaboration (on-site customers to make sure that we build what is needed), Frequent Feedback by delivering software to be used in the daily work and getting feedback about what needs to be improved and how we can focus the effort to make it even more valuable - in short - the big Lightbulb Idea is to simple have an ongoing conversation about the project with the people who will benefit from it.
12. Incomplete Project Plans
The symptom of this is that the project members don't know what should be finished when and thus have a hard time meeting these secret expectations.
This touches one of the areas where agile is really a hardline process. Planning-wise it is much more like situational planning in the war room than the big Politbureau meetings and their production quotas and five-year plans.
We work a lot with management to make this happen and it is very, very difficult to do well.
First, we advise a simple visual roadmap for the portfolio to put on the wall - just the big themes or strategic priorities on a timeline (don't add the details until the last responsible moment). In Scrum terms this is the "long-term" Product Backlog.
Then, for the next 2-3 sprints we have a Product Backlog consisting of a prioritized list of features to be done. They are explicitly managed according to trade-offs such as between the value they represent, the cost of doing it.
Then, for each sprint the team picks the top priority items and commits to delivering them at the end of the sprint. Along with this we have not only a short description of the feature to be done, but also two other things: Conversation and Confirmation.
Conversation means talking to the Product Owner to really understand how the feature should work. Confirmation is talking about the acceptance criteria, putting up a target and making it crystal clear for everybody how we will verify that we have completed the job.
The last thing is that the Team commits to what they can finish. We don't try to whip them into doing more. We say, "here is the most valuable things we can work on, let's estimate it and make good trade-offs to maximize the value created by your work, and then you, the people who will do the work, pick as much of the most valuable work that you can do without cutting corners."
It is simple, direct and takes a lot of discipline. It could also be seen as the Stephen Covey "Begin with the end in mind"-habit for software development.
13. The IT-department Does Not Reject Unrealistic Deadlines
The symptom is that the IT department has a reputation for not delivering on time.
The agile approach as outlined above is to have the team commit to what they can do, based on evidence of what they did last time. It is empirical and if we are honest and keep a consistent definition of done, delivering good, tested software at a constant high quality every time, our production capacity will soon be quite stable and predictable and something that can be measured rather than gamed. It is the end of overdue projects since we basically only commit to very small projects at a time.
On a bigger scale - say a 6-12 month project timeline, agile shifts the focus back to entrepreneurial thinking and saying, "OK Product Owner, we can deliver at this rate, how do you want to prioritize the effort." The Product Owner then, continuously evaluates the project business case and as long as the marginal utility of new features is better than stopping the project and starting work on something else, the project continues. It agile business, not just agile software development. And it is very very hard to do well since so many organisations are built on smoke and mirrors.
14. Poor Communication with Sponsors And Stakeholders.
Back to the basics again - "Customer collaboration", "Visible Status", "Frequent Deliveries", "Inspect and Adapt"... if you miss out on this point it is one of the best places to get started. Even if your organisation is not ready for "this agile stuff" you can try some ideas as suggested by Lee Henson:
"Instead of that weekly hour-long status meeting, how about meeting for 10 minutes every day to talk about the project"?
"How about keeping a visible list of the highest priority features to be built next?"
"Would you mind looking at the system every couple of weeks as we build and and giving us some feedback on how we need to adjust the priorities for what to do next?"
"Since we have already build the most valuable features first, shouldn't we put it into production and get a faster ROI? Maybe it is already "good enough" and we can finish early, under budget?"
I wish everyone great success in overcoming these mistakes and showing our profession better ways to work. The need is clear - and it is up to us to make it happen.