I wonder if you have seen it before: in the middle of Service Development project the team starts to suspect that the solution is wrong, user experience is bad, required functionality needs a lot of custom tuning, etc, etc. It all looks very different from what was imagined when the project was launched. We are already over the budget and time. “Stop the project!” they say in corridors, but for PM’s and managers with traditional delivery mindset it equals to failure. Does it really?
Let me skip the basics of Project Management: everyone knows them. Either hates or loves it, tries to master or ignore,- but knows that’s is’s largely about arranging as many things as early as possible; before the deadline hits.
After few occasions I started to believe however that while this traditional approach works for Delivery projects, it very often fails for Development projects.
- What I call Delivery project is something known, something what “just needs to be done”. Example is a setup of new Datacenter; an office move; consolidation or divestment exercise.
- The Service Development projects on the other side have their core in unknown domain; something what we didn’t do before of have little experience with. Example is new IT service or idea; consolidation on new platform; anything what needs to be researched and confirmed first.
Service Development projects, and their PM’s at first instance, must feel comfortable operating in the environment of uncertainty. While traditional projects try to stick to plans and milestones, development projects must stick to the ability to research and adjust in response to findings.
|Delivery project||Service Development project|
|Timeline and resources can easily be predicted||Timeline and resources can accurately be predicted short-term only|
|Project Manager can (and should) do as many arrangements well in advance, in parallel||Project Manager needs to confirm most risky assumptions before making arrangements dependant on them|
|Most decisions can be made at the beginning of the project||Decisions are being made during the course of the whole project|
|Design and documentation can be done at the beginning of a project||Design and documentation are best to be done after Proof Of Concept is performed, confirming technical assumptions|
|Project aims to stick to the timeline, milestones, and budget||Project needs a lot of room to “pivot”: to react to findings done during development process. Each phase may introduce changes in the planning.|
|Not delivering on time or on budget is a failure||A chance of not delivering according to the original plan is high and that’s normal. The planning and estimates must be done differently.|
Alex Mavrin, CCIE #7846
Visit http://www.apteriks.com and use FREE ONLINE tools for network professionals.