Fear No Project Blog – Focusing on the Management Side of Projects

Developing the schedule for a software project, especially one that is complex, may seem like a task equivalent to predicting when the stock market has reached bottom. That’s one of the best reasons I know for using predictive scheduling with frequent status monitoring and dependencies built in. But, I digress. Let’s say you are relatively new to the PM biz and you have been tasked with developing a software project schedule from scratch. How do you protect yourself, your team, and your organization from the risks inherent in this speculative venture?

In the best of all worlds, you will have an organizational history of developing similar software or solutions, a performance track record for the team members, and lessons learned from other projects. If any of this information is available, it gives you a solid foundation to begin identifying your project schedule risks and defending your estimates. Frequently, however, there is no good historical information to give you a leg up.  Your predecessor did not keep records or the organization didn’t value saving the history.  So you look at number of modules, estimated function points or how many lines of code need to be written, tested, and integrated. Then, you consider what potential risks must you account for in the schedule?  This is a key item for the project manager, because these are the things that will derail the project or cause all of the estimates to be woefully wrong.

What are some real world events that create schedule risks?
This list is not comprehensive and all of these will not happen on all projects. However, some of these events are likely to happen at some time during your project execution.  Therefore you should accommodate them in your risk management plan. (You do have a risk management plan, right?)

• Coming up to speed on the customer’s problem so the solution fits their operating environment and expectations (Sometimes known as startup time risk)
• Time required to learn and develop proficiency in new software tools, languages, hardware, or testing techniques (Also known as learning curve risk)
• Delays in receiving hardware or software—“The memory board must be lost in the mail”; “Our shipping clerk is on maternity leave.”; “We can’t find your order.”; “Our computer system is down.” (Also known as the Murphy law)
• Loss of a key team member
• Finding and training new team member
• Your partners are late delivering their pieces of the project
• Disruptive team member
• Shaking the bird cage—corporate reorganization, moving offices, acquiring a new company or being acquired (Also known as the Annual Corporate event)
• Interruptions from other critical, but not project related, tasks (One example is the holiday and vacation time in December)

Here is a bit of wisdom about scheduling and risk from the Herding Cats blog (“The Five Easy Pieces”)

1. Hope is not a strategy
2. All point estimates are wrong 
3. Without integrating Cost, Schedule and Technical Performance you’re driving in the rear view mirror
4. Without a model for risk management, you’re driving in the dark with the headlights turn off
5. Risk Communication is everything

So, if you are now sufficiently worried, how should you identify and manage software development schedule risks?

Brainstorm. As a new project manager, you may not be comfortable trying to identify all the schedule risks on your project. So, pull your key team members together for a brainstorming session. Create what-if scenarios. Talk about what can go wrong. Develop a plan to deal with these risks.

Seek out training. Make sure all members of your team are up to speed on the software tools and operating environment. Work with HR or senior management to offer classes or consultation to improve developer’s skills before you have to rely on them to produce within schedule constraints.

Do your homework. The Project Management Institute offers A Guide to Project Management Body of Knowledge (PMBOK for short) for about $50 (less for members) covering all aspects of program management including risk management strategies. Or, you can get an extension of PMBOK from the Department of Defense  as a PDF download. You want to check out Chapter 11.   There are also good blog posts full of tips on the web like Randy McGowan’s post at ProjectSmart.

Keep communication lines open. Not wanting to hear bad news is a trait we all share. But, as the project manager, you need to know the risks your project faces and you want to know when someone on your team is concerned about achieving the planned schedule. Also, your senior managers do not like surprises. Keep them informed of your potential risks and always have a plan to deal with it, because they will ask.

I feel strongly that it doesn’t take fancy tools and teams of people to manage risks—it just requires some forethought and planning to address risk as a part of any project schedule.  Some of you might smile and call this “common sense.”

What do you think?  Leave a comment with ideas you have on managing schedule risk.