This is a ramble. There is little originality in this post. It's quite long. There are some pictures. I'm OK with all these things.
Projects are a bit like road trips1. You know where you want to go and roughly how you think you'll get there, you have your team of people joining you on the journey and no amount of planning is going to ensure you get to where you want to be when you want to be there. That's just happenstance.
GPS
If projects are road trips then the GPS is your plan. Before you start off you plonk in your destination and after some internal calculations you get an approximate estimated time of arrival. It knows this because it assumes it knows what route you'll take and it knows a little bit about the roads that make up that route. From this data it is able to extrapolate an estimated time of arrival and total milage.
Most projects still have some element of an upfront plan. It may be very lightweight, just a figure like our GPSs ETA or it may be more detailed like the GPSs routing. Something upfront is useful for budgeting (or the approval of) and determining peoples availability for the project2.
The GPS and your project plan are both snapshots of the current state of play based on the knowledge they currently have. That massive 2 year Gantt chart that goes right down to the day level that you spent weeks on at the start of the project is immediately useless the day the project starts. The fact it may sometimes appear to be correct is purely by chance. Without taking current and historical data into account and updating the plan your information is lying to you. Having a flexible mechanism for feeding this real time information into your plan quickly is vital - an A1 dead tree Gantt chart mounted on your teams wall should be set on fire and the ashes scattered to the wind.
The plan itself is NOT a goal - it is a guess that gets better the closer to the real result you get.
I repeat the plan itself is NOT a goal.
Roadworks and accidents
There are some things a GPS system can't predict namely short term roadworks and accidents. Many systems incorporate some sort of up to date information about these things but not all. The minute you encounter a tailback from an accident or some other unpredictable slowdown in traffic the ETA starts slipping as the GPS uses the incoming data to readjust.
To reiterate - any form of project plan has to be able to use all available data. You can't simply assume the plan you came up with at your most ignorant is still holding true. The quicker you can adjust the plan the quicker you can notice trends and react accordingly. Overly detailed plans are usually both wrong and out of date and in that state the only thing they are good for is finger pointing and blame laying - two things that will ruin a teams morale and further damage the project.
Don't Miss the Boat
Of course the end destination (or even various destinations on your trip) may be time dependant. Perhaps if you have to catch a ferry. They may also be cost dependant too of course. Maybe you're a band of cash strapped musicians with £30 left to the next gig to cover food and petrol. Who knows, this is your fantasy - live it.
Anyway the GPS's ETA is still not a goal. Sure it is an indicator wether you'll meet your goal (or your ferry) on time but you can't blame the GPS for having an ETA that means you'll miss that boat.
In fact you can't even go blaming the manufacturers of the GPS - they developed an algorithm that takes all the information it has and, assuming that information is correct at time of calculation, tells you how long it will take. Things change. Understand that. We just have to do our best to ensure we get there when we need to by making sure we think ahead.
The same is true for projects. We'll not dive into why FPFT (Fixed Price and Fixed Time) projects are just horrible incubators for bad software and toxic environments. Instead lets focus on Fixed Price or Fixed Time. Many projects need to go live at a certain date. Incoming legislation may require it. The marketing department may have already made public announcements. Many projects can only get a certain amount of money because red tape demands it or a customers accounting practises are apply practises that don't fit well in the IT sector. The reasons exist for fixing some aspect of the project and they are many.
We need to ensure we can manoeuvre within these constraints. When something slips, and it will happen, we need to better understand how we can deal with this instead of trying manage expectations or deferring the truth until its too late.
It still amazes me that projects will spend longer on a piece of relative fiction like a detailed plan upfront yet pretty much skip any honest talk about what happens when the proverbial hits the fan and how to prevent such things.
Remember our GPS and its ETA? Well a plan that can be updated quickly and reflect the current state of play quicker. Make it visible. Like that little ETA on our GPS display that everyone can see. At any point in time, based on what we know, anyone can see if we are slipping and we can work out how to deal with a small slippage rather than waiting until near the end and realising you've missed the boat by a 1/2 a day.
Come See "The Largest Toenail in the World"
Road trips can be dull, even with the sweetest tunes and funnest friends, you'll realise that other peoples music sucks and everyone else has fallen asleep. You need to break up the monotony and you can do this by stopping at tourist spots. Get out, stretch the legs, change the scenery, have a nice long wee. Whatever.
Of course the more stops you have the more time it will take to reach the end goal. It may also take you out of your way and eat more fuel.
But you build this in. You can use the GPS to add via's and give you a more accurate view of how long it will take. You also add contingency. You leave the house a bit earlier to give you some breathing room in case anything or everything goes wrong. You agree that everyone is willing to miss "The Largest Toenail in the World" exhibition if it means shaving off some time to make that ferry or save some petrol. You check that tyre pressure and that oil to make sure the car wont suddenly explode.
Projects are no different except instead of visiting tourist spots we're talking about features. We discover what features people really need. We discover what people want but not need. We accept that should we risk missing our deadline or running out of cash we can drop non-essential features.
We de-risk scary parts of projects by addressing them early or spiking out our understanding of things we don't know yet or are afraid of. We need to question why we have certain features. Who requested that Oculus Rift enabled login screen or gesture based Rich Text Editor? Better yet don't question them. Come to a set of features by asking people who will actually use the system. Them beautiful users. Use them to build what users need. Build prototypes of features ahead of time, through the course of the project, to understand user needs rather than the vision of some middle manager who's never going to actually use the stuff they demand.
Most importantly communicate. Talk with your team. Talk with your customer. Be honest, be candid. Do it early, do it often. Small change, often, is better than monumental change right before a customer has to walk into a board of Directors and explain why everything is falling apart. People are going to be more open to change if they feel comfortable and trust you.
The more we know the better we deliver (though we may not deliver more or faster).
Easy Street
Not all parts of a road trip are fraught with risk like some terrible Mad Max B-Movie clone, some parts you could do blindfolded (not actually blindfolded mind you). Especially the start.
Getting out of the city, the one you where born and raised, is a piece of cake. You know those roads like the back of your hand, you don't even need the GPS at this point. Further on, you may have previously visited a village you're passing through and remember some local tips for avoiding that famous village market rush. You may find that you even shave some time off the journey.
You get this on projects as well. There will be points in the project that you or your team know so well through experience in a given problem or business domain.
It's a double edged sword though.
If you don't recognise this productivity boost is due to previous experience you may feel you're flying through the project smoothly when you may well be in the eye of a storm. If you can identify this as the cause of your new found productivity you can use this opportunity to reduce risk and further understanding. Try spiking out some riskier areas of the project. Imagine this like taking a new route on the way out of your city - it could lead to an even shorter journey. But it may not. At least now you know. You're keeping the risk low though as you are in familiar territory and can get back on track easily.
Take advantage and learn.
Flat Tyres and Engine Trouble
Cars - complex metal monsters rolling around on pressurised cushions of air and rubber. No matter how well you look after your car chances are something will go wrong with it. It usually something that can be fixed with a tyre or a fuse or a can of Radweld or something similar. You could call roadside assistance and wait for a few hours but you'd be going nowhere that whole time. But if you or someone your with knows how to change a tyre or replace a fuse you're going to get moving much faster. You may need to come revisit the repair later on but if a quick fix gets you moving (without compromising your safety) then you're going to make much better time overall.
Having a broad level of skill on a project team ensures that downtime for minor problems is minimised. I'm specifically talking about infrastructure and ops but the analogy can span design, testing and project management. The most productive teams I've been involved with have been the ones that can manage their own deployments in a controlled manner. They may have needed help getting the infrastructure up and running with a dedicated Ops team and have occasional reviews with Ops specialists to ensure everything is ship shape but all in all they were self sufficient for the most part.
Siloing specialisms may make sense from an organisational perspective but they add additional friction when it comes to the reason that organisation exists - project delivery. Cross functional teams should be nurtured.
The Town of Lost Souls
Sometimes your GPS is just not right. Data for out-of-the-way towns can be out of date and it can get you lost. If we're willing to accept stereotypes here, which I will, you're not allowed to get lost and if you do get lost you must not tell anyone. Winding your window down and asking the sweet looking old man how to get to Babbling Brook Lake, even though he so obviously knows exactly how to get there is simply not allowed. Instead, with absolute certainty, you know how to get there you make another lap of the town because you think you saw a sign - burning more daylight and fuel in the process. Eventually you admit you need help, swallow that pride and ask the next person who gives you the best instructions you've ever heard.
Communication on projects is essential. I'm not talking about awkward morning stand ups were people pretend everything is OK and waffle about stuff that they may or may have done when in actual fact they haven't even turned their computer on in days because they are scared of the code that refuses to work. I mean open communication in an environment that people feel safe and willing to admit they have problems. Admit you have a problem, allow others to admit the same. Then you can apply teamwork ointment and work through the problem together.
When people are in an environment that makes them cover up their mistakes and issues you end up with a bigger mess. When people are too full of pride or too cocky to admit they are having issues the team is in trouble.
Support and empathy go a long way to making people more productive.
Sticking to the Plan
In some parts of Ireland country roads are either completely empty or full of sheep. Get stuck behind a flock, yes that's the collective term apparently, of sheep and you just have to hope they're being driven to a field nearby. A strip of road that would have taken you 5 minutes to travel could now take you 30. However deviating from the GPS and taking an alternate route could save you time. It probably won't take you the 5 minutes the original route was, the GPS generally plots the quickest route, but it may not take you the 30 minutes that sticking to the sheep filled road would. Turning onto the road and allowing the GPS to recalculate may well reveal a better option than the original plan.
Projects are full of potential unknowns (known and unknown) and sometimes you hit roadblocks. Integration pieces may be delayed by a third party not meeting their deadline, hardware requisition may well get bogged down in red tape, people may get actually hit by buses. These things can well cause projects to stall.
Sticking to the plan could result in a significant amount of time where people are twiddling their thumbs waiting for work. Sticking to the plan is not always the best option. In order to keep people moving it may be necessary to find alternative solutions be it in the short or long term.
Changing a plan my seem a bit daunting especially when the impact of sticking to the plan is so vague but a team that is allowed to think and change fast can reduce any associated risk, cost and/or time.
The Big Finish
So we've almost made it to the ferry. It's due to leave in 30 minutes and the ETA on the GPS is showing 35 minutes. Lets allows ourselves to get a wee bit fantastical for this last one.
Cue wacky races music.
You've gotta make up time so you push that big red button on the dash marked "In Case of Emergency" and the boosters on the back of your car spring to life. As the G-forces press you into the back of your seat the car careers off the road through barns full of hay, chicken shacks full of eggs, back gardens full of laundry, fences, walls and just about every other trope in 70's cartoons. Just as the ferry is a few meters from the port you and the car make an amazing jump onto the only spare parking space on the ship.
The car covered in sheets, eggs, hay and dirt sags with exhaustion its engine sputters to a halt and a few bits fall of it. You and your travelling companions step out dazed, little birds flutter around your heads. You made it. Now the next leg of your journey can begin.
Most projects have some sort of timed delivery of features. It could be weeks, months or even years (shudder!) but irrespective of the time there will invariably be crunch times. Some worse than others depending on the project, the customer or just your companies approach to project delivery. The one thing about crunch time is that you move into "quick win" territory. Quality and "doing it right" become much less important as time becomes the enemy. "Ship it" and "just get it done" are the teams mantras now. It happens. I'm not saying its should be condoned but even on the best projects sometimes things align in such a way that it happens.
The problem is as quality goes down and "good enough" becomes significantly "less good" technical debt, bugs and other types of friction leak in. So once you push that deliverable over the finish line you need to ensure you have time after the fact to go back and ensure you clean up any technical debt and edge case bugs you may have introduced.
If you don't allow the team to address these issues you begin layering layers of debt on top of each other and one day someone will have to repay it. It may not be you, it may not even be a member of your team, but leaving a mess for someone else to clean up is just not something a decent human being should do. You want to be a decent human right?
Finishing up
I think I've stretched this analogy further than it really should have been stretched but I wanted to be as holistic as possible to the idea of team delivery.
As the old saying goes "Its not the destination, It's the glory of the ride"3. While it may seem, from a single customers point of view, that delivering the software is the be all an end all it's much more nuanced than that. It's about building relationships far more than software because it makes delivery of the end product much easier and increases the chance of delivering exactly what people need. It's about ensuring that your team are supported, allowed to take risks and further themselves both individually and as a team. Happy customers will come back for more, happy teams will stick around. Sure every project may not be all sweetness and light but people know this and it's how we deal with the challenges that make the difference.
1: At least for the benefit of this post. They are probably entirely different. Go with it.
2: "Resource Planning" - not even once.
3: Edward Monkton, Zen Dog