by Phillip Smith
In my previous article I wrote about IT projects experiencing trouble, and separated the symptoms from the root causes. Doctors sometimes treat symptoms, and sometime they treat root causes. Other times they treat both or do nothing at all. In this case, the project is the ailing patient, and the specific medicines that a project manager chooses to administer—and when—is largely a matter of style.
Some project managers are comfortable allowing a certain amount of churn to take place before they step in, while others work in a more hands-on mode. If the project team is seasoned and is using a mature development process, the PM can afford to allow that team space and time to work through problems without having to personally drive a resolution for each problem. There is a balance between empowering the team and being so distant that you appear to be “checked out”. Find that balance (it will vary by project and by team) and use it to your advantage. Teams that work independently within a process set tend to accomplish a lot – and they tend to have great morale when they are productive and know they have a PM who will drive resolution for issues when they need that kind of help.
While I’m willing to admit that the PM has a right to bring a certain amount of style to their approach, I’m also willing to make a strong argument that various situations call for certain “medicines”. In the last article I listed classic symptoms of a project being in trouble. One of these was “high defect rate.” We can use that as an example of a situation that calls for specific action.
No one wants to pass defects downstream through the development process, such that a bad requirement results in an incorrect design, or that an incorrect design results in code that does not function correctly. Defect rates that are “normal” will be corrected within time frames that the project plan allows for rework; however high volumes of defects will stress the rework portion of the project schedule such that other tasks slip, or such that some defects remain in place to be corrected later, exposing the next phase of the project to proliferation.
One way to treat the symptoms is to borrow additional resources to identify and close product defects within the original project schedule. While this course of action will negatively impact the budget, it prevents proliferation, protects the schedule, and keeps things moving in a positive direction. There are times when this prescription is called for. However, in most cases I would argue that the patient is still ill, and that more defects will be introduced later in the project because the original root cause for the first set of defects was not addressed.
A prescription of doing nothing in this example may still result in the symptoms being addressed. Specifically, the PM may turn the open defects back to the project team and require that the team fix them with overtime or some other method. This will work in some limited number of situations; however it still leaves the root cause of the defects unsolved.
The project manager who schedules time for root cause analysis into their project plan will have time to work with the project team on each defect to determine why it occurred. Some common root causes of defects are:
- Incomplete training (people do not know the technology and/or do not have the business domain knowledge)
- Unavailability of system documentation
- Inaccurate task estimates (people hurried)
- Wrong people assigned (incorrect use of people’s natural talents)
These four items are much more difficult to deal with than the actions above that deal directly with symptoms (overtime, push-back to the project team members). Adding time and budget for training team members, completing system documentation, or re-estimating tasks is not likely to make the project manager popular with the stakeholders. Changing the people on the project is not always an easy thing to do either.
However, in a situation where the project manager needs the project team to be successful not only on this project (or phase) but on many more projects to follow, the best course of action is to fix the root cause, re-plan accordingly, and then proceed with caution. Fixing the root cause is always a conversation that is worth having with the stakeholders of the project. The stakeholders may not be able to tolerate the impact on this specific project or phase, but they will appreciate the project manager to making the attempt to look out for their long term interests, which will result in increased respect for the PM.
In my next article I’ll discuss health checks and why it is important to understand risks and potential root causes when planning your health checks.