May 26, 2017
How would you build the Pyramids and an underground railway system? Part 3 of 3.
By: Suraj Rai

In which we explore how to deliver, handover and finish a project.

In the last post we looked at step 2: the planning phase. There we explored different methods to plan and set them out tailored to each project. In this post, we’ll look at how to now deliver, hand over and finish the series.

Step 3 — Control and track the project.

In which we build things and track how we’re doing.

It’s time to get started. You travel in time to the build site for the Pyramids; a large sunny dusty plain. Next you time travel to the city to a rainy build site. The teams begin to mobilise. So now we’ll use our plans to guide them on what to do and when it happens.

This is the moment where you’ll be time travelling the most between Egypt and the city. You’re doing this because as the project lead you’re going to want to check on the health of your projects repeatedly until they’re finished. There are several different tools you could use to do this. These range from weekly status reports, to delivery metrics, to simply talking to your different teams.

Whichever ones you pick you’ll need to use parts of them to update the Pharaoh and the underground railway stakeholders on your progress. You’ve involved them throughout the project starting at the requirements, presenting your plan and now you’ll need to create a method in which you share your progress, consistently.

This isn’t just a courtesy, it’s crucial for the success and eventual handover of the project. Reporting to and involving your stakeholders throughout the process is important so that there are no sudden surprises in the end delivery.

Your previously created milestones will be a particularly helpful guide to track your progress here.

Image 1

At the start of the project you’ll also need to be looking intensely at crucial setups before the project progresses too far. Things like cementing team structures, clarifying responsibilities and defining the flows of information across your teams.

It’s important to troubleshoot this early on, because your teams experience will grow as they work and you need to make sure it’s growing in the right manner before behaviours become entrenched.

At this point one of the most important things a project lead can do is set the culture of the project. Like a small company, values of trust, respect, openness are welcomed but it’s going to come from the leads setting this out by acting in that manner. If things are going wrong, then it’s a good step that you’ve cultivated the correct culture to rectify it.

The work goes on. Some parts slip up, other parts proceed on. You time travel back and forth assessing, supporting and guiding.

>Ultimately once you have the processes setup you need to trust in your teams and yourself to deliver.

Step 4 — Testing

In which we make sure what we’ve built is good.

The dusty plain you were at in the last phase now has a very a large, Pyramid like structure in it. The city has begun to start moving trains underground.

Eventually you’ll have to hand over what you’ve created. So, you need to make sure that it’s OK to do that. We don’t want an angry Pharaoh after all.

This check stage could involve multiple types of tests with and without stakeholders. What’s important about this stage isn’t just to make sure things work but to re-evaluate them against the original agreed requirements.

In this process, you might find all manner of bugs like not enough seats on trains, or perhaps the shape of pyramid ceiling isn’t grand enough. Even in the most perfect projects there will always be faults to fix.

Image 2

All of this is fine because we’ve setup mitigation time from our planning phase, specifically for scenarios like this. So, you’ll need to use the time we set aside to do something about them before handing it over.

Step 5 — Success!

In which we attend launch parties and reflect on how to improve.

The council of time travelling project managers approve that you’ve built two very distinct amazing things. Not just in architectural terms but in terms of what they deliver for the stakeholders and will do. The following two launch parties of your projects are great.

Slightly worse for wear after all the celebration it’s time to reflect and learn from what you’ve done to improve.

Image 3

Thinking back, you started by gathering requirements, refining them and planning them out against your project, then you followed the plan, tested what you’d created and then delivered it.

It’s not easy to take words, dreams and thoughts from stakeholders’ minds and turn that into something real.

However, these scenarios have had quite a few assumptions within them. For example, enough time with stakeholders, decision makers making decisions, enough budget, agreements on your prioritisation and more. It’s also never straightforward to accurately estimate how long a given task will take. Especially when factors like risks and dependencies from other teams are considered. Even the most perfect project may overlook new technologies or other outside influences impacting your project.

Ultimately, these can and should be discussed with your stakeholders. Overall having a plan, involving them and trying to adapt will always be the best practice.

Time travelling abilities have made delivery so much easier in these scenarios. However, most of us don’t have these abilities to hand. We can only remember what we’ve done and apply them to experiences going forward.

After all the real skill comes from managing with the time you have. So, go and build great things.

Popular Tags

    More blogs on this topic