Going backwards is sometimes the only way to go forwards

I was recently drafted in as Project Manager on a redesign project for one of our clients. The project had been underway for several weeks, the team were all very busy, the ‘work in progress’ boards showed that lots was being worked on but the ‘accepted’ and ‘live’ parts of the board were worryingly empty. There was a project plan but it was clear the team weren’t delivering against it.

I observed what was happening in the team over the course of the next week or so whilst trying to get my head round the requirements. The team were doing daily stand-ups reporting in on what they were working on, everyone seemed to be working on unconnected component level user stories.

The team were complaining about the designs, they were inconsistent, kept changing, looked OK for print but wouldn’t work for the web, didn’t work if the content (which was content managed) got longer etc. etc. etc.

Many stories had been started but couldn’t be finished because they were blocked for one reason or another. If the team got blocked, they just started something else.

The team were demoralised, they weren’t getting any sense of progress, couldn’t see the big picture and nobody was doing anything about their frustrations.

One day I asked a question about how we were going to put the redesigned site live. The customer was going to need to do some content population in the live CMS so we would need to let them do that without the risk of the new pages going live before the client was ready. Some of the content on the existing site was going to be re-used but would need to be available in the new designs. Stakeholders would want to be able to see and approve the new site before it went live but this categorically couldn’t be on a URL that just anyone could access – even within the organisation concerned access to the new site would need to be restricted.

When I asked the question everyone in the room looked blank, the team hadn’t thought about this, nobody had asked the question before and there were no ideas.

So we stopped. Mad as it sounds, on a project which was running behind time, running over budget and with nothing actually delivered we decided to stop work. Anything we did was pointless, we weren’t getting anything accepted or live and we had no plan for getting things live.

We don’t like to deliver bad news, but if we have bad news we don’t try and hide it and we deliver it early. We called the customer, we told them we had a problem, we said we were behind plan and that we were going to stop and re-think the approach. Understandably they were concerned, they were adamant that the dates we had given them weren’t moveable, they said they didn’t want to have another call like that again and that they wanted us to update them when we had a new plan.

The senior developer and I then got together and talked about the problem. We took a fresh look at what we needed to deliver and simply printed out in colour all the pages we needed to build. Whilst our backlog of component level stories looked scarily unachievable, the number of pages we needed to build looked far less daunting.

We had a team of 3 developers on the project. All we needed to do was a page a day between the three developers and we’d still have 2 weeks before the go live date for amends, launch plan and as contingency. Was a page a day feasible or should we ask each developer to produce one page each every 3 days? We talked about the strengths of the team – one of the team was a whizz at HTML/CSS, another had a lot of Sitecore backend experience, another was a good all-rounder.

The Senior Developer bought the other developers into the room and put the ‘page a day’ challenge to them. They agreed they’d all prefer to work together, doing the things they were each best at and they were happy to commit to doing a page a day with a ‘we don’t go home unless we’ve met our goal’ attitude. They were fired up, they had something tangible to aim for, it would be really easy for them to know if they’d achieved what they wanted to.

My job as the Project Manager having got that commitment from the team was to make their jobs as easy as possible – clearing the path ahead of them.

I talked to the client about the inconsistencies in the designs and we consolidated a number of the components which were similar thereby reducing the work that was needed (and producing a better user experience). I asked the designer for an updated style guide confirming which fonts, colours, buttons should be used where and when.  We agreed the style guide was the definitive version of what we should follow even if the Photoshop files we had didn’t.  Before we started work on any page I suggested that we’d do a final sanity check that we were working to a confirmed/signed off design to minimise changes later.

We agreed that any ‘changes’ after delivery would be added to a backlog which we wouldn’t look at until after all the main work was done. We’d then prioritise the changes and decide which were ‘must have’ for launch and get as far down them as we could. If there were more ‘must have’ changes than there was time available the client accepted the fact the date would need to slip but that the slippage would be down to the organisational wants/needs and not our inability to deliver what we’d committed to.

We told the client that we wouldn’t start any story that we weren’t confident we could finish and get approval on. We set the client expectations about the time/effort this would require on their part and got their commitment to make the relevant people available on the right days to sign off the work.

We agreed that getting a page ‘done’ for the customer to sign off was getting it all the way through to a live environment and onto a URL to which we could restrict access. This required a change to the architectural approach and we had to spend several days unpicking and re-doing some work we’d already done. But it was absolutely necessary.

Our new plan and approach massively de-risked the launch of the new site. Code was going to be deployed up to live every day. Those that had access would be able to see the site coming together on the live servers, they could update content on the old site and see it in the new designs, they could add new content. In short on go live day, all we needed to do was a configuration change to point the site URL at the new site we’d created – no downtime for the end users or for the content editors.

With renewed vigour the team jumped on the new plan. We stuck those printed out designs on the wall in ‘to do’, ‘doing’ ‘done’ columns and every day those designs would move across the columns and we’d see the progress. The increased production with the team working together rather than independently was amazing to see. If one person finished their piece of the jigsaw early they’d help someone else out. Every day they were doing a new page, some days they did 1.5 or 2 pages.

Daily stand-ups became unnecessary, the team were working so closely together with the same daily goal that they were communicating non-stop all day across the desks. I didn’t need to ask whether they were on track or how they were doing – I could see and hear it.  The client didn’t need updated project plans or status reports – the teams progress was visible every day by the release of something new.

The team delivered the site on time and under budget. The client was able to use the spare budget to include some changes and new features they wanted. The launch day was as smooth a transition as anticipated, literally a push button exercise to switch the new site over. The client was over the moon. The team were buzzing and had a real sense of ownership and pride in the end result.

It was a real team effort and a project I thoroughly enjoyed working on (even at the most stressful times) with a great team of committed professionals (you know who you are).

Here’s what we/I learnt:
• Spend enough time planning up front – don’t be tempted to dive straight in to the work
• Don’t assume every project or piece of work is the same and that processes which have worked before will work again – look at each challenge with a fresh pair of eyes
• The power of a team is far greater than the sum of the individuals – play to your strengths
• Think about getting things live early and how you’ll launch – de-risk big bang launches
• Don’t start what you can’t finish
• Tackle impediments and issues, head-on (frustrations and moans often hide an impediment)
• If it’s not working don’t be afraid to stop and rip up the rulebook
• Find a way to see your progress – nothing gives a greater sense of achievement
• A problem shared is a problem halved – getting the team ideas and commitment is better than telling them what to do and making the commitment for them

Project Management: How Much Contingency do I need?

Unless you’re managing a project with zero risk (unlikely) then before you can commit to budget or timelines you’re going to need to do some contingency planning.

How do you know what the right amount of contingency on a project is?  The short answer is you don’t.

If you’ve worked with the client, team and technology before then you can use your previous experience to give you a good idea of costs and the level of contingency you’ll need.

If it’s a new project for a new customer or you’re using new technology or you’re working with a new team or external suppliers/dependencies then the project comes with a higher risk factor and any calculations or knowledge you’ve previously gained are unlikely to apply.

Many PMs start off by adding a blanket contingency e.g. 20% to the costs and time of any project however it is hard to articulate the idea/cost of contingency to a business stakeholder (especially in a pitch) using this approach.

You can make a more calculated estimate as to how much contingency you might need by applying a bit of thinking early on.  Contingency is linked to risk so a good method to use is Risk Analysis.

Some typical risks that you may want to mitigate by adding contingency on a project might include:

  • The scope of the project changing as more becomes known
  • The initial estimates of the work may been inaccurate
  • You’re working with unknown technologies
  • You’re working with third party dependencies e.g. release management, hosting, APIs

There are of course other ways to mitigate risks other than adding cost/contingency to the project which we’ll cover in another post.

A simple way to calculate a contingency would be to multiply the % probability by the cost of impact.  For example a risk probability of 30% multiplied by a cost impact of £10K would result in a contingency of £3K.

You are then able to very clearly show business stakeholders your recommended contingency to mitigate any risk (far better than a blanket percentage).  They are able to make a more informed decision based on their appetite for risk as to whether they want to include any contingency or they may decide to accept the risk and understand that the project may cost more.

Many project managers like to include a second contingency amount, often known as the ‘programme contingency’. This can be used for risks that were not identified at the start of the project and emerge later.  The larger and more complex the project the more likely it will be that you will uncover more risks later on.

There’s no sure fire measure or magic formula to help you establish ‘how much contingency is enough’.  As you get more experienced you’ll be able to make more educated guesses.

The most important thing you can do is to make the contingency visible and get sign-off from your stakeholders (internal or external).

If your contingency is agreed you should keep it as a separate budget from that of your main project and the aim should not be to use it up or count it as profit on a project.  Having contingency budget left at the end of a project will put you in the stakeholder’s good books.