Rescuing a complex project part 2: the art of the possible

I outlined the problem I was faced with in Part 1.

After answering the focusing questions:

  • What are they missing that they need?
  • What do they value that they haven’t got?
  • What is frustrating them about what’s happening now?
  • What are the symptoms of the problem?

Read on …

The list of requirements

This discussion assumes that there is a list of requirements with enough detail to work on them available. If you don’t have that you will have to create it. This list is vital to making sure that everybody agrees what needs to be done and what the finished project or product will have in it. If you can’t nail this list down you will always be making small changes and things will never be “done”, for whatever definition of the word you want.

Managing the list

I went on to look at the art of the possible. The first thing is to win the political battle.

  • Find some quick wins can we find to help the client demonstrate to their stakeholders an improving situation.

Then I created a MoSCoW list:

  • What Must be done
  • What Should be done
  • What Could be done
  • What Won’t be done

One very important thing is to acknowledge that you obviously can’t have all the things you asked for. Taking items out of scope so what can be achieved fits the resources available is a good first step.

Fortunately, in this case we had a clear list of things that simply hadn’t been done. Plus there were some bizarre oddities like the original supplier decided they didn’t like the client’s design and implemented their own because it was “better”. As you can imagine this didn’t help with the already fraught relationship.

More often the creation of a MoSCoW list in pressured circumstances like this is a difficult conversation to have. This is because the client wants everything on the original list. Quite often things were put there because they think that there will only be one opportunity to get what they want, so they tend to throw in everything they can think of. Of course this often means there are new things that occurred to them after the first few iterations.

When filtering the list I also use the key concepts of avatar, fit to ship, and delayed implementation.

Avatar

You need to work out who the avatar of the system is and what they needs are. Asking those questions allows you to filter the requirements you have down into the core things that really matter to the project’s ultimate user. It also stops fruitless arguments that come from different understandings of the avatar’s needs.

Fit to ship

Another way to control scope is to look inside the items on the list and see what parts of them need to be done to meet the immediate needs of the avatar. Make things that are fit to ship and ship them. Defer or even don’t do things that are nice to have. So you create another MoSCoW list for the components of elements that made it through the first filter.

Delayed implementation

There is usually a “drop dead” date that the shippable version of the project must be ready. You are probably under pressure to produce something that is functionally complete by that date. A bit of lateral thinking can really help here. For example, say you want to be able to bill people a month after the system has gone live. You don’t need to ship the billing right away, you can use the people you have to work on things that are in the must part of the list for the first release.

Estimates and contingency

I believe that it should be mandatory to put in at least 20% contingency on top of any estimate. Estimates tend to follow the optimistic path and don’t take into account new requirements or misunderstandings. In my experience the contingency always gets used up because the client has room to change their minds without it being a big problem.

Without a decent amount of contingency you end up having arguments about scope or having to use some time wasting (and usually expensive) change control mechanism to manage any problems that come up. Change control systems usually magnify trivial changes into big ones.

Contingency should be added to the estimate as a whole. Adding it to each task is confusing and very hard to manage. You never know where issues might crop up and need to be able to use the reserve where it’s needed.

Wrapping up

In the event the project finished on time and within the revised budget. I also felt the understandable kudos of replacing an entire agency and out performing them. I managed to do some things that were supposed to be impossible, for example making the site multilingual.

That said, the client recruited an intern to work with me and we would never have got it completed on time without her help. I also reached out into my network and got a very competent colleague to help with the design changes because I knew he could do them far more quickly than me.

Success is built on the team.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Posted in Agile practice, Developer, Project rescue