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

In which we explore how to setup a project for success through planning.

In the last of the post we looked at step 1: the requirements phase. There we met our stakeholders and thought about what the projects mean. In this next post, we’ll look at how to setup a project for success by planning.

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.

Image 1

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 railway system, it could be 2 months split across specific tasks like digging, securing and laying tracks for a tunnel.

Image 2

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 underground system, 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.

Image 3

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 Stakeholder’s visions. Because making sure you both are consistent on what you are going to do and when is key to agree.

Image 4

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.

In this post, we’ve explored different methods to plan and set them out tailored to each project. In the next post, we’ll look at how to now deliver, hand over and finish the series. 

Popular Tags

    More blogs on this topic