Define Priority Tasks By Value

When it comes to prioritising the product backlog it can be a challenge to order the items based on what is most urgent and important because these attributes are not measurable. Urgent and important are emotional factors based on opinions that are not all created equal, it can often be led by the loudest voice in the room despite volume not being a historically good indicator of ROI.

When defining product backlog items there should always be a measurable against the proposed work, if it doesn’t have a number it cannot be measured. Product backlog items without a value proposition can exist in the product backlog but should never be positioned higher in priority than a deliverable that has a defined number value that will come from the delivered work. When there is an idea without supporting data I recommend storing such an item in an “Icebox”, a list designed to understudy the product backlog until such time that a given item gains a value proposition to be promoted to the product backlog ready for development.

This is where Data Science delivers value and prevents waste, the organisation knows it has a problem and data can help define where that problem lies and what value a given change could be expected to deliver.

I like to refer to the next stage as Data Driven Development.

With the backing of data analysed to understand a problem and propose a desired outcome, the development team are handed more concise direction to deliver a potentially shippable product come demo day. This approach to delivery allows all parties to know and understand what a development team is doing and why they are doing it at all, along with why they are doing it first.

Prioritising an item that will save £1000 per month over an item that will make £200 a month is a simple decision and makes prioritising fast. There will be times when a stakeholder will throw their weight into the mix and make the decision for you but by educating all involved that value is the number 1 priority of the delivery team to best serve the organisation you can ensure a teams efforts are being put to work on the right things at the right times.

Example

Item A is estimated to take 2 developer days to deliver and will yield a benefit earning of £300 per week.

Item B is estimated to take 4 developer days to deliver and will yield a benefit saving of £800 per week.

By prioritising based on value delivered to the organisation I would focus on item B because although the work will take more effort and possibly more time, it will be of greater benefit to the organisation. This is the 80/20 or Pareto principle at work, whereby 20% of your effort will deliver 80% of your gains. Over time you are aiming to be delivering smaller and smaller value items knowing the big ticket items have been completed and you are now squeezing out the smaller, but also beneficial, value tasks.

This task also helps to flush out valueless tasks. On multiple occasions I have observed tasks created and constantly pushed down the priority list to be addressed later, only to see that item hang around for up to 2 years. I say up to 2 years because that is my cut off point from a task being declared to me actively deleting the item completely.

If nobody has acted on something in 2 years the task is definitely not priority. I’d even say a task that does not move from Icebox to Product Backlog in 6 months is just an idea someone had at some point but were not willing to put in the time and effort to define the specification.

If you do not put in the effort to communicate a desired outcome effectively, you cannot expect a development team to put in the time and effort to guess, based on substandard information, what you expect to be presented on demo day. Declare the value proposition, define the outcomes, and empower the team to deliver the best solution to achieve those outcomes.

Embrace Uncertainty and Creativity

Management wants Control and Predictability. This desire creates large numbers of documents and overly described plans outlined to the finest detail, colourful charts and graphs designed to impress and persuade rather than educate and ensure. For the facade of control and predictability to take shape months of planning must take place to cover topics and areas that are intended to prevent mistakes and ensure work is delivered in time and on budget.

The scenario is appealing to management because it suggests everything is under control and what is expected to happen will happen, only it never goes to plan. No industry as a whole or company, whether it be a new startup or a long standing company, is exempt from the reality that all that planning months in advance and knowing the unknowable is waste. Waste of time, money, and resources that could be put to better use.

Projects with vast plans and projects born of inspect and adapt cycles both equally involve periods of discovery and innovation, the only difference is inspect/adapt cycles are expecting this and have saved the effort put in upfront on projects seeking Control and Predictability.

Trying to control teams of bright and creative people to charts and graphs is a recipe for disaster, it’s not how successful teams work or a practice that leads to successful projects. Ideas are ignored and great minds are wasted. People get frustrated, projects get delayed, budgets get eaten.

Embrace Scrum

Scrum asks the important questions and gets right down to the issues that see projects overrun. Why does it take so long to deliver? Why are we bad at figuring out how much effort is required? Why do attempt to predict the future without any pre-existing data?

Scrum embraces Uncertainty and Creativity, the latter is exciting while the former is terrifying, but together these two attributes feed each other to help organisations ensure they are creating the right products at the right time.

Embedding a learning structure within an organisation to enable a team to make an assessment of what they have created and how they have created it. By looking at how teams actually work, rather than how we think they work, the processes are in place to empower a team to self-organise to improve the speed of delivery and quality of outcomes.

The core of Scrum is based on a simple concept; inspect and adapt on a regular basis. Organise regular check-ins to reflect, down tools for a period of time and consider if you are heading in the right direction and delivering what people end users actually want. Are there ways you are doing things that could be done better? Any ways of doing it faster, or contrasting your thinking and asking, are there elements of work that are actively slowing you down? What might prevent you from going faster and delivering higher quality outcomes?

Taking this approach injects an element of energy into a team that is disruptive in the short term and requires honesty, introspection, and discipline, but in the long run pays dividends to the overall delivery velocity.

Control and Predictability are just a pipe dream of the optimist, and planning is just an exercise in looking busy and faking value in an effort to fabricate a rosy future for all. Nobody is ever held responsible months or years down the line when the project is over budget and past deadline, but someone lied to themselves and to the company buying in to the fortune teller tale.

Control and Predictability only comes from empirical evidence acquired by observation and experimentation. I can’t tell you when a software development project is going to be done by, but given a few sprints I can assess the available data and give you an honest prediction that will grow more accurate each iteration. Embrace Uncertainty and Creativity, you have employed the brightest minds to deliver the right product at the right time so empower teams to inspect and adapt regularly to deliver more outcomes in less time.

Reflect Honestly In How Say You Work As A Team vs. How You Actually Work As A Team

One of the key skills of any successful team is the ability to be honest and open about performance of individuals and teams. We can all be drawn in by the, “it’s always worked this way”, mantra as if it is some sort of infallible holy tradition. It’s easy to do this, why step forward to put your head above the parapet and question months and years of working practices? There are a few good reasons, particularly if teams are not profitable and likely survive off the back of other profitable teams – a truth I have seen in multiple companies over the years.

No team should be unprofitable month after month, if they are then there is a requirement and responsibility to reflect and adapt. Nor should teams that are profitable believe they are exempt from reflection just because they are financially positive, to declare you can improve no further is to be so arrogant that you become the most recent casualty of, “it’s always worked this way”, rhetoric .

Toyota and Royal Marines

The Toyota production system has often been referenced as the success story that gave birth to the modern Agile movement. I recall learning about this in college one aspect of Toyota’s transformation stuck with me strongly.

Toyota removed the hierarchy that meant workers and managers ate lunch separately. Instead, all Toyota employees ate lunch and took breaks freely mixing with other at various levels in the company. One of the outcomes of this integration was the discussions that were had between those on the floor doing the hands on work and those in the offices delegating and directing the work. Workers were able to share real experiences of problems and propose solutions that managers could then act upon to improve the process. Workers had their problems solved, managers looked good for improving performance and the relationship between workers and managers created greater cohesion towards a shared common goal and purpose at Toyota.

Similarly, I have read a number of books about war and I remember the story of how the Royal Marines, as part of a wider force, made fantastic progress “yomping” across The Falklands at a rate of speed that the Argentine forces did not expect. This is fairly well know in the public narrative but there is a smaller aspect that I really like.

A troop of marines found their advance halted by a fixed machine gun nest, a well fortified defensive position that pinned down enemy forces very effectively. The marines were held at a distance unable to make much of an impact with their rifles and light support weapons. A lowly marine suggested to his troop commander that maybe they should look at their problem a bit differently. They had weapons designed to combat small forces of soldiers and they had heavier weapons designed to combat light vehicles and armoured vehicles. The young marine suggested using a weapon normally designed to attack a armoured vehicle from a distance, to attack this machine gun nest.

There was no rule to say only certain weapons could be used in such a situation but it can be appreciated that a troop would assume using similar weapons against a defensive position is only fair. By changing the game, as any victorious force has in military history, the marines were able to dispatch the position quickly and easily by introducing an approach that had not been considered before, or at least not widely shared.

If You Had All The Answers You Could Do It Yourself

The reason we have teams of people is that we cannot do it all ourselves. If we could we would do it ourselves, it would be much cheaper. The fact of the matter is that the more minds you apply to a problem, the richer the solutions you will get as an outcome.

It does not matter where someone sits in the hierarchy either, you can be the head of a department with 40 years experience yet that is no replacement for a young mind to enter the game and not play by the rules, either literal or mentally imposed on the self. Likewise a young mind is no replacement for experience, but combine these and you have a powerful alliance to approach a problem from a different perspective to a less forward thinking organisation.

Honesty Is The Best Policy

It can be hard to admit a mistake like not having improved a process sooner, but a process has to be improved at some point so why not now and why not review it regularly? Approach your working practices with a “Strong Opinions, Loosely Held”, that is to say you are very sure and clear on your opinions but it does not hurt to be open to and welcoming of other opinions that will inevitably shape your own.

The aim of the game in modern organisations is to target objectives, big and small throughout. These goals have various measurable outcomes depending on the goal but there is one aspect I have a strong opinion (loosely held) and that is that everything you do should be in an effort to promote your superior and at the very least ensure they don’t get fired. Being bold and articulate to improve a team and your own individual self only serves to accelerate a teams velocity, being able to change a single process in some way that can easily double the output of many workers, which has a powerful multiplying impact.

Teams Are Cells

Teams are like cells, they maintain a state. You inject energy into a cell and there is a disrupting effect on the state, a period of instability and confusion results until quickly the disruption calms and a new state is reached and maintained.

This is how everything works in the world at a cellular level. Never fear change, embrace it and assess it. If the change is positive you can welcome it with open arms as part of the family now, and if it is negative you can expel it entirely. Without the trial you will never know what works for you and your team, it is stagnant to fear change as an ultimate end knowing that change is fluid and can be changed back and changed forward on assessment.

Don’t fear change of how you do things, or what you believe. You were not born knowing everything, actually you were born knowing nothing at all about the world so don’t let ignorance and arrogance lead your mindset – don’t be a baby.

Gantt Charts and Trench Warfare

In 1910, Henry Gantt popularised the Gantt chart, a method of visualising a project schedule ahead of time and selling the promise of delivery on time and on budget. The problem is they are almost always wrong.

Save for the lucky break where a Gantt chart turns out accurate, the vast majority of Gantt charts will end up being nothing more than a means to win a bid. The colour coded and pretty charts are designed to convince a buyer that everything has been meticulously planned and the future has been set on this humble piece of paper, nothing can or will change this indisputable document.

The trouble is they are fabricated lies. Those creating Gantt charts for the first time will be optimistic and excited to present to a client what bright future lay ahead, the people who have created Gantt charts before know the truth however. They know that this is just another tool for winning the work, and after this has been done the chart should be discarded as quickly as possible with no mention of it again, and the hope that the client will never bring it up again.

Can You Be Here By 10?

We have all planned a journey of some sort in our lives, whether it is walking or cycling to school, hopping the train to London, or Driving 300 miles to meet a client in Kent. Although these journeys are more specific to me, you can appreciate the similar journeys you have had to plan and may even be planning as you read this.

With any journey you have a proposed departure time and matching arrival time between 2 (or more) points. Google Maps has a great feature that provides you with information about your journey and the methods you can choose from, you can say you need to be somewhere by a certain time and the tool will tell you when to leave.

Everything is very precise and confident. Except it’s not precise at all.

A short journey may be 20 minutes and you might make the actual journey in 21 minutes or 19 minutes on the day, this might not seem like a problem as it is only a small discrepancy. What about a typically 2 hour journey? You’ll notice Google Maps will give you a range of time from 2 hours up to 4 hours, what’s going on here?

Well the journey on average is expected to take 2 hours but outside factors encountered when the rubber hits the road can double this or more. What about if there is rush hour traffic conditions, or an accident, or difficult weather. What if your own vehicle breaks down or there is a tree across the train tracks?

This isn’t uncommon at all and Google Maps knows this, which is why they promise nothing and only act as an ideal case guide to your journey. The point here is that any good plan will not survive contact with the enemy for long, something will happen and you’ll have to adapt to try and make up time down the road bringing greater risk to the journey such as a speeding ticket or being pulled over adding more time to your journey.

Your Project Is A Journey

You plan and prep and plan some more before you begin the project. Day 1 arrives and everything is going as planned, by the end of the week you are bang on target and feeling good. The second week encounters a small problem but it is to be expected and is addressed and resolved quickly, no problem. The following week a worker falls ill, the rest of the team pick up the slack. The next month a supplier fails to provide and you have to scramble to find a new supplier, while referencing the Gantt chart to ensure the project timeline is maintained.

You spend most of your time looking at the Gantt chart and at your project progress, back and forth over and over. As long as the stage ends on time and the next stage starts on time you will be ok you tell yourself, only it’s not ok is it. Quality is suffering and workers are rushing to deliver something rather than deliver the thing that was promised during the bid process.

Deadline day arrives and the project is not well received, the quality is not up to standard and you’re out of time. The client isn’t happy with the product, they needed what they expected today but now they have to go back to their own stakeholders and ask for forgiveness and more time to allow you to catch up. Now you’re eating into your profit in an effort to deliver.

You focus on delivery of the product, just barely getting something over the line, it’s just good enough. Embarrassing. The client have lost confidence in you, your team, and your organisation. Your organisation has suffered as a result of this project, the finances aren’t good and the team morale is low, good people are thinking about leaving.

The forecast for the year is looking good though! We have another Gantt chart to show the team that everything is going to be great in the coming year, plenty of clients in the pipeline with some cool projects and enough work to fund the business and pay salaries.

It’s another lie. This time it’s from within, and sold to internal staff and teams. You’ve seen this all before, you tell yourself something has to change.

Trench Warfare

The bull headed ‘stick to the plan’ mentality of a Gantt chart led project is the same sort of mentality that saw the forces of WWI stall to a halt. Teams of demoralised men slowed their progress to a stall out with the enemy, digging in  across no-man’s land within sight of each other but with no alternative or creative adaptation to consider the plan they had been fed on day 1 was not viable 2 months into the campaign.

Throwing more resource at the problem didn’t help either, the ‘over the top’ orders just led to more risk and waste. A campaign that was expected to last a couple of months ended up lasting for over 4 years, I’d posit we have all been involved in at least one project that has taken longer than planned but hopefully not at quite the scale of WWI.

Learn And Adapt

Gantt and Trench Warfare are one in the same, a mindset born of arrogance and a lack of honesty and integrity. These lessons of the past should be treated as such by the modern world, WWI cost the lives of 20 million people, an incredible waste nobody looks back on with fondness. A further 21 million were wounded, enough people to reflect first hand and begin asking the questions of how this happened at all.

In business you may not be working in a domain where lives are at stake but it is your responsibility to treat waste as if it could be a persons life at stake. When something goes wrong it should be assessed, if it happen again it should be investigated and owned to ensure it never happens again. Learn from past experiences, adapt future approaches to problems and give yourself a chance to over deliver.

Facilitating Effective Stand Ups

Daily stand ups are usually conducted in the morning, although sometimes occur later in the day particularly when there is a distributed team involved, and this often means that team members arrive unprepared to share what they have been working on. It may have only been 16 hours earlier that an individual was focused but it takes time to get the brain moving and the creative juices flowing.

I have facilitated thousands of daily stand ups and there are a few things that occur during a given project, almost without exception, that need to be addressed and ultimately resolved.

Arriving Late.

The daily stand up meeting has a start time so that time is not waste, and that is the top priority for a scrum master – eliminating waste. If the team is left waiting for a someone to arrive they are left waiting, impeded by the uncertainty of that persons attendance, as a scrum master it is important to address the negligent party and appeal to their conscience that they are wasting multiple people’s time. It is a matter of respect and value that bonds a team with the level of cohesion required to deliver quality outcomes.

If an individual is not on time, continue ahead as scheduled and do not stop or become distracted if they arrive mid ceremony.

I have even taken the step of locking the door on a completely glass office so that when the repeat offender arrived and found they could not get in, it really hit home how disconnected this individual was to the team and that corrective behaviour should be considered for the good of everyone.

Laptops and Other Devices.

Nothing says, “I respect and value your contribution to this daily ceremony”, like hunching down into the glow of a screen while other people share with the team. Frantic typing is also not a great indicator that you are listening to your fellow team member.

Playing games on your phone like Candy Crush Saga equally not a respectful stance to take when other team members are listening and collaborating to deliver desired outcomes.

Come Prepared.

This last one is a given but often people arrive unprepared to share with the group and frantically search their memory for what they did 16-24 hours earlier, or take over the sprint board to remember where they were at 5pm the day before.

By coming unprepared to a discussion you end up spending the time when you should be listening to others, thinking about what you are going to say. I’d argue this is as disrespectful as the examples above because you are all set up, distractions aside and ready to listen but you have chosen not to.

Imagine how you would feel if when it got around to your turn to speak and you raised a point already addressed by another member of the team, a perfect opportunity to contribute and collaborate at the time, and saw the look on the rest of the teams faces. They know you weren’t listening and now you are expecting them to actively listen to you?

At the end of a working day simply grab a post-it note and jot down what you did today, what you plan to do tomorrow, and any impediments you would like to raise.

Not only will you benefit from being a confident team member ready to share and unimpeded to listen and collaborate, but you will also get better sleep that night knowing your thoughts and goals for the next day are safely written down ready for you.

Be Willing To Have Difficult Conversations

As the Scrum Master it is your responsibility to the team to eliminate waste. This can come in many forms but when it comes down to people and people’s actions or inactions, the required response is often to have a conversation.

It is easy in the short term to go in guns blazing and demand an end result, but you will only end up “winning” the point and “losing” the respect of the team member you are there to serve. The better course of action is to speak privately with the individual so not to have them lose face among their peers, and to highlight your perspective and the possible perspective of others relating to their behaviours.

Reflection is a powerful and empowering thing that enables and individual to take control, to be self-organising, and grow or simply heal as a valued and respected contributor to the team.

A person’s success in life can usually be measured by the number of uncomfortable conversations he or she is willing to have.

The real “win” is to facilitate the reflection so that the individual in question can arrive at the answer themselves. It may feel hard to do for some, especially early on in your career but it will have a strong correlation in the long run to the success of your career.

Facilitation is a truly difficult skill that allows for a desired outcome to be arrived at without the threat or application of force. To facilitate your team is to serve their best interests as a whole, as a tribe and community working towards a shared goal. Serve well and all will be rewarded.

Team Specific Retrospectives

At the end of an iteration you are probably running a team retrospective with specific decisions defining the goal, key markers, and how the session should flow. It can be all too easy to repeat the same retrospective format over and over, asking what went well and not so well, what can we start doing and what should we stop doing in the following iterations. Before doing any of this though, it is important to investigate and learn the right approach just as you would over the course of a development iteration.

Even in the event you have been leading retrospectives for your team and have a good idea of the history and context of the group, check your assumptions and have another look at the team’s historical record, morale, job satisfaction, and energy relating to the current state of the project.

When working with a team outside of your own take a moment to study their surroundings, where individuals work in relation to one another and how they interact on a day-to-day basis. Appreciate how they operate during ceremonies, what they do and do not do along with what artifacts they maintain and if any artifacts are missing entirely. The information you gather will help guide the team to an appropriate goal, utilising your observations to offer questions to ask around problems the team is facing.

Questions to ask yourself as Scrum Master

  • What was achieved during this iteration, what was committed to at the start of the iteration and how did the resulting outcome match up against the expectations?
  • What factors going on elsewhere in the organisation may be affecting the team?
  • What happened in previous project reviews and how were the action steps of those ceremonies received and addressed?
  • What are the working and personal relationships within the team and how do these affect those involved and those on the fringes?
  • What is the team excited about and what anxieties do they hold?
  • What outcome would provide value to the project sponsor and team members for the time invested in a retrospective?
  • How has the team received and worked with facilitators in the past?

Set a goal

Time is an important investment for a scrum team so it is important to define a goal at the start of a retrospective to gain team buy-in to spending the time reflecting on the most recent sprint.

A retrospective goal should be broad enough to allow your team to think creatively and be open to possibilities based on their experiences and insights. Unlike traditional goals the retrospective goal works best if you do not define a measurable outcome.

Determine what can be assessed instead of what can be addressed. You want to reflect on what happened during a sprint by having an open and honest forum to discuss and bounce ideas freely amongst the team. By focusing on addressing something from the outset you are preventing the consideration of other aspects and directing the discussion.

How long should a retrospective last?

45 minutes per week of work is considered a good starting point, although it is best to use this as a rough guide and not a rule. Look at the team to get a feel for how long the retrospective should last and consider these factors:

  • How long is the sprint iteration?
  • Overall complexity – tech stack, relationships, departments
  • Number of people in the team
  • Level of conflict/controversy

A sprint retrospective is a reflection of the most recent sprint, while a project retrospective reflects on the length of the project and should be afforded an appropriate duration. To take shortcuts on the time allowed is to cheat the results and benefits that come out of retrospective reviews. An hour may be enough time for a sprint review but a project review can require a whole day or longer in some cases.

Preparation

As the facilitator of a retrospective you should spend an adequate amount of time planning, ensuring the logistics have been considered and there is an appropriate set of activities to engage the team for the duration of the ceremony.

Early on it can take as long to plan a retrospective as it does to conduct it with the team, over time this period will reduce but you will never require zero planning. To not prepare at all for a retrospective would mean you’re not thinking about it at all, which is a recipe for failure and a disservice to those taking part.

Facilitating the Retrospective

Outline the structure of the retrospective so everyone involved is aware of the plan, making sure to set aside the largest portion of the session to gathering data and generating insights. Take breaks at logical stopping points.

Encourage equal participation and new perspectives with a focus on the conversation, helping the smaller voices to be heard and boosting the confidence of those perhaps anxious of sharing what might be a controversial contribution.

Choose activities that require team work and collaboration to deliver results and mix things up by pairing off with people in the team that do not normally work together on a day-to-day basis.

Provide paper and markers so that insights can be captured in a highly visible way. Arrange insights on a board for all to see and ponder over throughout the session, ensuring no one insight is diminished because of the quality and colour of the paper combined with the quality and clarity of the marker. I like to use Post-it notes and Black Sharpies, there are enough similar shades of post-it notes to group contributions by colour if needed without a significant contrast and black sharpies are big enough and bold enough to be read from a reasonable distance.

Reflect on the Retrospective

It is important for a team to reflect on the most recent sprint, and it is equally important to reflect on the retrospective. A retrospective focuses on all the ceremonies, artifacts, and interactions included during a sprint while the retrospective itself is easily forgotten as a key aspect of the iteration.

Gaining feedback and insight about how the retrospective has been received and performed will help the facilitator to learn and improve going forward just as we intend to in Scrum. By gathering feedback and acting on this feedback you will garner greater respect and participation in future retrospectives leading to a constantly improving cycle of reflection to help remove waste and accelerate team performance.

What Waterfall Development Taught The FBI Post 9/11

In March 2010, The Federal bureau of Investigation dropped its most significant modernisation project, a project designed to prevent another attack like those on 9/11. The FBI had been trying to update their computer systems for a decade and once again the most recent initiative had failed. Jeff Johnson arrived at the FBI in 2009, encouraged by the CIO, Chad Fulgham, a previous colleague at Lehman Brothers, and now he found himself in charge of clearing up this mess.

Jeff had been Assistant Director of the IT Engineering Division, with a big office in the J. Edgar Hoover Building overlooking the Washington Monument. Despite this lofty position Jeff spent much of his time in the basement attempting to salvage a project everyone saw as already sunk.

After 10 years and hundreds of millions of dollars the plug was regrettably pulled with the decision being to bring the project in-house to be “done and done well”.

The project was a computer system to replace the filing of paper reports in the modern era of Facebook, Twitter, Amazon, and Google. The typical special agent trying to get anything done, from paying an informant to filing a report on a bank robber, continued using the process their peers had been using 30 years earlier. Writing up a document, printing 3 copies; one sent up the approval chain, a second stored in case the previous copy got lost, and a third used to manually index keywords into the database.

Approval was sent in an equally slow and dated process that was regularly blamed for a systemic failure to maintain a clear picture. Analyst’s for the 9/11 Commission couldn’t even get access to the information due to the poor state of the FBI systems, which could not be relied on to scale beyond small groups of individuals. Many factors were identified as to why there had never been a terrorism threat assessment carried out but the report singled out “woefully inadequate” technological sophistication.

The FBI lacked the ability to know what it knew: there was no effective mechanism for capturing or sharing its institutional knowledge.

The FBI responded with Virtual Case File (VCF), intended to ensure the failings of the past would remain there. They had already budgeted $100 million dollars and just needed another $70 million to see it through.

The FBI spent $170 million dollars on a computer system program that was dropped 3 years later before anyone could ever use it. Not to worry, in 2005 the FBI announced Sentinel, a $451 million dollar replacement designed to go live by 2009. All the budget controls and procedures missing years earlier had been taken into account to ensure successful delivery.

By 2010 Lockheed Martin had delivered half the project at a spend of $405 million dollars. Independent analysis proposed the project would require a further 8 year and $350 million dollars to complete.

What Went Wrong?

It is all too easy to point the finger at possible causes like the wrong people or technology, but the reason these programmes failed is in the way people work.

The people at Lockheed Martin spent months preparing to bid on the contract, looking over the requirements and planning the system architecture. They spent months planning how to do the work from beginning to end, producing beautiful Gantt charts to reassure everything would go smoothly.

The Gantt chart laid out every milestone and  delivery date, a complete picture of the future designed to assure the FBI that time, budget, and scope would be met. The problem with Gantt charts it they are always wrong.

No person can predict the future, and with so many possibilities to derail a prediction the odds are that the prediction will be wrong. In the event a Gantt chart is proven right, chance is a wonderful thing.

Gantt charts appeared prior to WW1 and were used in 1910 by General William Crozier, they have since been carried through to modern day project management and unfortunately the stubborn nature of trench warfare and “over the top” tactics remain popular.

Lies and fabrications hidden behind colourful charts may win contracts, but responding to change over following a plan is realistic and will successfully deliver desired outcomes on time and in budget.