Best Way to Manage Project Risk in Software Development
Throw out your GANTT chart and start focusing on being a resource provider to manage software development risks.
By Howard Young
I was in the process of writing the Software Manager’s chapter for Fast, Quick and Agile, where Risk Management (RM) is perhaps too large of a topic and requires a separate appendix to fully cover. Thus, what is developed in this article is somewhat premature for publication in book form and mostly highlights the main concepts in RM.
Hopefully your organization is developing software under a defined repeatable process where you can monitor and measure steps during each project phase. This is absolutely essential otherwise you are just identifying issues rather than actively managing and correcting them.
RM is all about Relationships
The nice thing about GANTT charts is that it shows relationships between tasks. If a task slips, the dependencies get pushed out identifying schedule delays and cost overruns. The bad thing about these charts is that they are a real pain to maintain.
I remember back when I first started managing projects, we updated the charts by hand. Before our weekly meeting with the S/W Director, we would fill in the tasks worked on with pencil and erase and redraw the ones with slips. Of course today, with MS Project, schedules are instantly redrawn, but none the less still a pain to maintain.
Back then there was little or no risk management other than his inquisitive look at the multiple erasures and rescheduling from the baseline. His invariable question of “was there a scope change?” due to the new schedule was indeed fact to the relationship between requirements and software development costs. Plus he had a legitimate reason for renegotiating any delays and budget overruns.
Risk Management is Requirements Management
Since requirements are the driving factor in the development life cycle, risk management should be done with respect to the requirements. At the very top-level, the customer wants a “system” and depending on your level in the organization, all you may care about is the state of the project and potential impacts to your “customers.” For example, cross-functional teams depending on the “system” are just as important as the real customer since there may be a rippling effect to future business if your project is late or over budget.
- GREEN: On time and on budget
- YELLOW: Late or over budget
- RED: Late and over budget
From there you can see which areas need addressing. From your perspective, the project is either late or over budget. If it is late, you can reassign personnel to the problem areas to bring it back on schedule. If it is over budget, you can start collecting costs based on requirement scope and feature creep, or perhaps the project was underbid and doomed to run in the yellow or red stage for the duration of the development.
Cost and schedule allocation for derived requirements – or child stories in Agile – are normalized to the original cost of the top-level requirement or user story. That is, the sum of the parts are not greater than original baseline. If you happen to get an extra requirement in which does not add up, I suggest flagging this “red” because this is going to impact budget and schedule. Until relief is given, the requirement is going to impact the project one way or another.
Usually we work with obscure concepts which we are trying to develop, so we take an educated guess at the amount of work required to complete the task. More often than not our estimation is off – high or low – and we suffer a variance. Decomposing the first two generations of user stories and estimating the implementation cost of those requirements yields the best project estimation.
This is our process when bidding a job:
- Provide an Architectural Diagram
- Identify user stories and child stories
- Identify number of interactions with users
- Identify number of interactions with subsystems
- Identify the data model
- Identify the controller
- Identify special algorithm requirements
These values are used as inputs to a Feature Points estimate for the project and converted to man months for cost and schedule.
As a manager, you really should standardize on points regardless if that is Feature/Function Points or some arbitrary measurement which allows you easily convert between hours and development output. This way you can improve your estimation process with measured feedback. I prefer Function Points simply because you can obtain a very good initial estimate and measure the output per requirement. In addition it is possible to go back and forth between lines of code produced and FP’s so you can always do a post-mortem to optimize your estimation process.
How Do You Know When You’re In Trouble
Do the Potato Chip 1-Sigma Test.
One of my first software managers told me a story he heard about a major potato chip manufacture. When the volume of sales sold by their reps fell below one standard deviation, they were fired. I don’t know if this was urban legend or in fact company policy, what we can learn from this example is that you need to measure the output vs. what is expected. Any significant deviation in either direction needs to be understood.
What is expected is the number of points your company can produce per man-month. What to measure is somewhat more difficult. A useful technique is to have inch-stones per requirement and weight them accordingly. It is a good practice to bind the achievements to discrete functions such as design, code reviews or any other defect removal technique used by your development team. Give partial credit per event thereby adding up to 100% when the implementation is tested and completed.
Risk management in software project management come down to three principles: measure, monitor and resolve. By focusing on these elements, you can manage the risk by understanding and appropriately reacting to it.