Wanted: Service Development mindset

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.

WindyRoad

Advertisements

One comment

  1. Andrey · · Reply

    I would say that in “Service Development project” much more attention needs to paid to “pre-project” phase, in particular to gathering/formalizing/refining requirements those are quite often vague at the beginning. In my opinion a success of such a project depends very much on transparency of requirements and criteria used to determine solution quality. That requires a lot more involvement of the solution (or service) customer.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: