They key in this work is showing people how things are going to play out as the project progresses. Will you stay on schedule? Will features be descoped from the final release? How will everyone feel about the project when it's ended?
Now it’s time to get into a particular technique that you may be able to use. The fundamentals of my proposed approach are to use the requirements traceability activity combined with control charts to monitor how stable requirements are over time, and to raise the alert early so you can take action.
As discussed, we already know requirements are going to change in some way or another. Our job is to anticipate the changes and to help our team mates manage the time, schedule, budget and quality constraints to deliver the best results possible within the available constraints.
And at the same time we have an opportunity to open a dialogue with our clients and customers about the issues we face as a team. Together, with our clients we can often find innovative ways to get more out of our limited resources. And in some cases, they’ll go to work on increasing budget and schedule for us.
We start this example by reacquainting you with the control chart. You track performance within controls. Too high and there is a problem. Too low and there is a problem.
This applies to project scope. You have a budget allocated to you and if you underspend significantly you have been sitting on funds that could have been spent elsewhere. If you overspend... well we all know about that scenario.
Given that you know requirements are going to change over time, and that the resulting work effort will have to change, how can you going to use a control chart to help you out? Simple. Plot the planned set of requirements on a period by period basis.
(What period? Weekly, fortnightly, monthly, whatever works for you.)
Next up: Handling the variations.
0 comments:
Post a Comment