How would you build the Pyramids and the London Underground?

In which we explore methods of project management and delivery.

Congratulations you’ve got the promotion. Your new job title is Time Travelling Project Manager. You’ve been given a license to time travel and you’re now member of the council of time travelling project managers.

It’s a coveted role and as a test to new members the board have given you two projects. To build the Pyramids and build the London Underground simultaneously. Time travelling in between of course.

In the historical responsible, accountable, consulted and informed chart (RACI) you are now both responsible and accountable for the correct and timely delivery of these wonders.

To clarify it’s not you physically building them but rather the teams who you’ll manage. On the line is your new licence to time travel, the historical importance of the projects and the status of your role.

Of course, you probably already know best, but let’s think about how you might need to go about this task.

Step 1 — The Requirements phase.

In which we understand to deliver something we’re going to need to understand what it is we need to deliver.

This phase introduces key players into our projects. We’re going to refer to them as stakeholders. What you’re after here is essentially to get clarity on some key who, what, where, when and why questions.

Who is going to be using it? What does it look like when finished? Where is it going to be? When do you expect this? Why do you want it? The last question is particularly important to understand as it’s the guiding motivation for why you are building something.

Our stakeholders could be divided in all manner of categories and they would also sit within our RACI. In our scenarios, they’ll be the ones who will be affected by and ultimately use what we create. We’re going to talk to them to find out what they’d like to build.

Travelling back in time to Egypt you meet with your biggest stakeholder, the big boss, the pharaoh.

His absolute mandate means we can pretty much focus our time on him. Across a week you record his answers to your many questions on your papyrus project plan.

From your conversations, it becomes clear that the Pharaoh is after classically shaped Pyramids for himself. He’s not worried about what stone it’s built with but it is important that it needs to be a few miles overlooking the Nile and built in 5 years to commemorate a personal anniversary. Eventually, it’ll be his resting place before his journey to the underworld.

A single decisive and powerful stakeholder has outlined their expectations and requirements for the Pyramids.

Leaving your Egyptian garments for more modern attire you travel in time to London for the Underground project. Here the numbers of stakeholders for your requirements have grown, significantly.

Some of these stakeholders will hold higher priority than others for the success of the project. So, your invites and meetings will have to vary. They range from the mayor, businesses, commuters, school children, tourists, to government ministers, home owners, pets, engineers and more.

The list you gather from all these stakeholders is long. Possibly containing items ranging from seat comfort, to stop locations, to the shape of the tunnels. Similar to stakeholders some requirements will be of higher priority to address than others.

From these meetings, we can get an overall idea of what we’re going to build; an efficient underground transport system for lots of people. However, London’s infrastructure, population and the technology it uses is continuing to change rapidly. This change is going put pressure on you by shifting the priority of your requirements and generating new ones continuously.

This is something we’ll address in the next phase.

Step 2 — Planning.

In which we use what we know to create a plan of what we’re going to do.

We’ve finished gathering requirements and it looks like an odd list. Written in hieroglyphs and in English.

It should be clear that each project is different. To deliver each one you’ll need a tailored plan to turn those words into something real. To craft this you could split your process into refinement, estimation, scheduling and presenting.

This is a tricky phase because it’ll need you to consider factors like time, cost, technical feasibility, stakeholder personality and the dependencies on all other requirements. It’s also important we get this right as it’ll set the tone and pace for the rest of your project.

We start at refinement first; because the gathered requirements are probably good but they could be better.

For example, you need to remove hidden duplicates, clarify conflicting ones, gather additional details and feasibility with all the other requirements. You’ll also consistently need to refine them in a way that aims for what your stakeholders want. Remember the why question?

After refinement, we’re going to need to break those requirements into clear sets of tasks and estimated times.

For example, for the Pyramids project 2 weeks could be split into tasks like carving a stone block and then pushing the blocks into place. For the underground, it could be 2 months split across specific tasks like digging, securing and laying tracks for a tunnel.

Once estimations of activities are in place we’ll need to order them into a schedule. This is to make it visible for everyone when certain tasks should be done and this is also where things get particularly interesting across the two projects.

The Pyramids have a single point of completion and a generally static set of requirements. The project’s general fixed nature allows your plan’s approach to be a step by step process. Each phase being handled by their subject experts. Stone carvers for example start before handing over to the transporters who then hand over to movers and so on. This project could get completed step by step with a logical schedule.

The London Underground, as we found earlier has a continuously changing set of requirements. This is due to the city’s growth, technological change and the wants of the population.

This project’s continuously shifting status needs a plan that allows you respond to that change. For this you might agree that you need a certain agility.

An Agile plan is different primarily because it should continuously focus you in on the most important task, where the value is at the time. It also has additional components like self-organising teams, blended handovers and close working areas.

As an example setup, all your refined requirements would sit in a backlog. This is the store of all that will be built. This is controlled by someone we’ll refer to as a product owner. As their name suggests they should fully own the product that’s being built. This means they have a final say on what will be built, when it will be built and if it has finished being built.

The core development teams could be made up of a mix of skills. This could be architects, engineers, developers, communicators and one lead. Each team member has their own area of expertise and responsibility whilst the lead has the responsibility of facilitating this team to work together.

Tasks are fed out to teams from the backlog, these can change depending on where the highest value is at any given time. For example the Olympics is coming up so focusing on infrastructure for priority stations becomes of high value.

This flexibility to adapt is why we’re using it for this project. There are also additional ways around how these teams could communicate and progress, however what’s here is a core process.

Despite the two plans being distinct both need to have a set of milestones, capacity for mitigations and time to test the delivered build. These are all still part of scheduling.

Milestones are important to use as a measurement tool for progress. If you miss a few dates for your milestones, then it’s clear that your project is behind schedule so, you’ll need to cut into your mitigation time. On the other hand, if your milestones are being met quickly, you’re ahead so you can save the mitigation time.

Eventually you will hand over what you’ve built so you’ll need time to test what you’ve delivered. If you find faults, then we’ll use your mitigation time to fix them.

All we need to do now to move to your next phase is agree it with your stakeholders visions. Because making sure you both are consistent on what you are going to do and when is key to agree.

So, you prepare your best Egyptian and your best presentation. Remembering to present the plan with vision and clarity is important especially as your stakeholders will most likely have some amendments before you get the green light.

Overall at the end of the planning phase we now have a set of refined requirements, a scheduled plan tailored to each project along with sets of milestones and mitigation time.

We’ve invested a lot of time here so we need to reap it’s value by making it visible and not disregarding it as we get going.

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 London to a rainy build site. The teams are 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 London. 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 London Underground 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.

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. London 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 ceilings isn’t grand enough. Even in the most perfect projects there will always be faults to fix.

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.

Thinking back, you started by gathering requirements, refining them and planing 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.

Feedback on this article in any form is always appreciated.