A project goes off track 1 day at a time

http://www.dreamstime.com/royalty-free-stock-photo-flag-beach-image4485135If you have been in the software development business for a few years, you most likely were involved in a project where there were multiple technical challenges, lots of requirement changes, new requirements being added two days before the release and team members start blaming each other for bugs and mistakes. In the end, you had to work long hours and sacrifice week-ends to make it all happen.

Sounds like a familiar scenario? Don’t worry. You are not alone.

According to a recent research made by the McKinsey & Company on software development projects:

  • 66% go over budget
  • 33% go over schedule
  • 17% deliver less value then predicted

Despite these scary facts, few people are willing to admit the possibility that one of their projects may fail. The psychology is exactly the same as wearing a helmet while riding a bicycle or in-line skating. It’s hot, uncomfortable, and you tell yourself that nothing will happen. You have been cycling since your early age and you are now riding slowly on bike paths.

Most people don’t want to wear a helmet until they have witnessed or have been involved in an accident. This mostly occurs because of our past experience, overconfidence in our skills and ego. They may also feel that admitting the possibility of failure will distract them from achieving their goal.

Many project failures could be prevented if a business and technical risk assessments would be done prior the project’s launch. Once the project is launched stay alert, watch, listen for warning signs and be willing to take action.

The main issue with projects in general, is that there are only two statuses: On track, Off track. Just like the frog in the boiling water, you never realize your project is heading for the wall until it’s critical. Here are few reason why this is happening:

  • Trust
  • Estimations & buffer
  • Communications

Because of the creative nature of software development and with the arrival of new technologies, it’s very difficult to accurately estimate a project. You need to plan for unexpected issues, calculate the project’s complexity, plan your resources will executing the project as you estimate. This is very important since a person with less experience will take more time to accomplish a given task than a more experienced developer. Also, the quality of the work may differ due to the lack of experience. For this reason, you will have to plan more time for quality assurance. This is why project managers secretly add extra buffer’s just in case developers underestimate the time required. Finally, the product owner will most likely add more buffer just to be on the safe side. So far, the process is fairly normal since you can never be too cautious.

How did we get there?

As the project moves forward, various technical problems occur which may or may not be reported in daily status meetings. Most developers will wait until the buffer is almost all used up before raising the issue with the team lead. Some issues (technical or not), may be raised and fixed right away. Other will come back and haunt the project for a long time. Since the project manager & CTO have an overall buffer for the project, in the grand scheme of things individual issues are not really a problem until the buffer is entirely gone.

Upper management is known to be very patient and tolerant, until it starts looking at the project and realize the true progress or the overall budget. Only then, the project gets flagged as an off track.

The main issue here is that most people count their buffer as part of the overall budget/time allowed to complete the project or task. This results in people not raising the red flag until they start digging into their buffer or even worse when their buffer is no more buffer. In this case, raise the flag is too late. In reality, the buffer should not be seen as part of the overall budget but rather as an emergency reserved.

You should only pull your money out in case of emergencies or unpredictable scenarios!

How can we prevent overtime, headaches and project failure?

The very first rule, is to break down your large projects into smaller ones and do an estimate for each one. This makes it much easier to estimate and reduce the risk of the overall project.

When doing an estimate always provide 3 scenarios and color code them (green, yellow, red) : optimistic, normal, pessimistic. Reserve one column in your project management software for each of these estimates and track the progress. Closely monitor the progress or your project for any yellow flags. Request that any access to the emergency fund be logged and require approval by one of the superiors.

Here are a few additional things you can do:

  • Watch and listen for warning signs
  • Do not discard information that is accompanies each sign.
  • Keep the upper management in the loop and involved in the project
  • Be honest with all team members including upper management
  • Raise the yellow flag when you are at 50% of your allowed budget/schedule
  • Raise the red flag at 75% of your allowed budget/schedule
  • Get an unbiased opinion from someone outside the project or the company regarding the status

Keep in mind that a projects never goes off track in one day. It goes off track one day at a time.

Every time someone says this will only take a few extra hours to do or fix, it really means those extra hours will eat your buffer and that you may trigger the project to be yellow or red flagged.

What signs should you watch for?

Join me this October in:

  • Cape Town, South Africa on October 3rd-4th at PHP South Africa
  • Johannesburg, South Africa on October 9th at Tech4Africa
  • Budapest, Hungary on October 11th-13th at RuPy

You will discover

Can’t make it to those events? I will be publishing a book on the warning signs in IT projects soon.

south-africa-speakertech4africarupy-speaker-badge

Your project is an investment, treat it with great respect.

When starting a new project, many people make the mistake of not only defining the wrong goals, but also don’t analyze the potential outcome. It’s understandable, since it’s much more exciting and rewarding to go and start implementing a cool project than talk about what could happen. However, it’s much wiser to fully understand what can happen in case something goes wrong. A person that took the time to do the exercise will take all the necessary precautions to prevent bad things from happening.

In Quebec, we have what is called the RRSP season. Most people visit their bank and talk to their financial advisor regarding retirement investments. A good financial advisor will take the time to ask a few questions that will help them identify their ability to take risks. For example, a few month ago, I wanted to make an important personal investment. Before suggesting a solution, my advisor asked me: “What happens if you lose all this money? How will you feel? Will it be the end of the world?” Today, I am glad I haven’t invested in gold back then. For those who are not aware, gold lost about 44% of its value since September 2011.

If your advisor didn’t ask you these questions, I suggest that you move all your investments elsewhere. Your advisor does not have your best interest in mind.

Your IT project is an investment too, and you should threat it with the same respect. Since you and your team will spend multiple weeks discussing and implementing the project, everyone on board should see it as a personal investment. A great way to do that is to imagine all the great things you could accomplish with that time or money. You could spend that money on a vacation or invest it in your retirement plan. You could spend all that time with your family, on your favorite hobby, sport, vacation or you can spend it on this project.

Seeing it as an investment helps put things in perspective. Make sure everyone in your team understands this concept. Doing so will translate into higher commitment, higher quality, efficient solutions and shorter delivery time.

Before we move on, let’s define what is a project risk.

RISK = Potential out come ÷ ability to handle the situation.

Let’s identify the potential outcome in case of failure of your project. The main question you should answer is: What happens if I fail this project? Here are some great point to explore:

  • How will this outcome affect my relationship with my boss, partners, peers?
  • Will they trust me with such project in the future?
  • Will they trust my judgment when I give advice?
  • Will my investor be willing to give me another round of financing?
  • Will the company be able to recover from this loss?
  • How will this impact the company financially?
  • How will this impact the company’s image and reputation?
  • Will my boss lose his job, will I lose mine?
  • How will I personally feel after investing all that time and energy into this project?

To help you visualize everything, I invite you to download and print my risk assessment guide. Write down all your answers in the grid. To each point, assign importance and ability to cope with the risk.

At this point, I assume that you already defined your goals according to my previous article: Is your project a success? If you haven’t done so, take the time to do it now. This is crucial for the success of your project.

Print your project’s objectives, potential outcome in case of success and potential outcome in case of failure. Put them side by side. Take the time to fully understand the implications.

These documents are the cornerstone of you project. Keep them close to evaluate the success of your project and use them as motivators.

You like this article?

Stay tuned for more upcoming insight on identifying project threats and establishing safeguards for the success of your project.

Is your project a success?

Sometimes it’s difficult to say with certainty whether a project is a success.  Throughout the implementation of the project you may have had technical difficulties, time constraints, poor team dynamic, etc. All these come in an can cloud our judgment regarding the overall success.

There is a famous misconception that many project managers gurus and PhD owners propagate on how to measure the success of a project. Here are some of the measurements I found:

  • Scope
  • Budget
  • Team satisfaction
  • Quality of work
  • Customer satisfaction

These are not metrics of success. They are constraints that one or a group of person decided to dictated to the implementation team to navigate between. You manage to respect all these? Great work! But was the right problem solved?

Constraints are usually flexible. For example to ensure objectives are meet you can:  change the scope of the project (add/remove features), shrink or add extra funding, reduce or increase work quality.

Objectives precise and static. Team Canada wants to win the gold medal in Hockey at the next winter Olympics. Throughout the year they will train towards this objective. During the Olympics you don’t see their coach telling them they now need to win gold medal in curling.

The best way to determine objectives is to work our way backwards. Start by defining the end goal. In what discipline do you want to win your gold medal?

Here are some good questions that will help you determine what are your objectives:

  • What are we trying to achieve for our clients?
  • Why are we doing this?
  • What is the desired return on investment?
  • How will this help improve our reputation?
  • How will this affect the way our customers, investors and competitors perceive us?

If you haven’t started your project, it can be very tempting to talk about tools and methodologies to us. For example, you might define one of your goals: build a mobile application and API to increase our readership. This is very limiting. You might not need a mobile application or even an API. At this point, tools and methodologies  are irrelevant at this point, since they are a means to an end.

Here are some example of clear objectives:

What are we trying to achieve?
Our current platform is very buggy.  It takes us days of testing before being able to deploy safely. We want to reduce the number of bugs and the time required between each deployment.

Why are we doing this?
Most music service that recommend music do it very poorly. We want to change the game and become market leaders in defining customers taste and suggest them relevant artists based on their taste not on what their friends listen to.

What is the desired return on investment?
The expected ROI over the next 6 month is expected to be 10 thousand dollars. In three years, it will represent 20 millions.

How will this help improve our reputation?
By increasing the productivity of our assembly line by 40%, we will be able to dedicate more resource to quality control. Our customers will appreciate the reliability of our new high end tools.

How will this affect the way our customers, investors and competitors perceive you?
Our online image is getting outdated, by creating a more engaging website and mobile application our investors will see us as an innovative company who means serious business when it comes to delivering on time quality content to the Canadian Citizens.

Take a few minutes and do the exercise and write them down. This will be your most important piece of knowledge for your project.

Not only will it help you assess your project’s success throughout the implementation and at completion. It will help you put things in perspective as you explore ideas, methodologies and implementation path! Even better, it will give a meaning to the implementation team and motivate them.

If you haven’t been able to define the goals of your future, on going project stop everything immediately. Take the time to go back to the drawing board. You probably don’t have a project and will waste a lot of time, money and generate much frustration for you, your team and your partners.

Success all comes down to achieving the desired end result. Olympic athletes set their objectives to win a gold medal in a specific sport and their sponsors evaluate their success on how often they climb on the podium. Not on how many times per week they trained or what type of food they ate.

Do projects really fail or do they just disappoint?

I recently had a conversation with some project managers regarding project success and failure. In this conversation, multiple arguments were brought up and motivated me to write a series of articles on project management. This series will deal with the following topics:

  • Why do people feel the need to diminish the importance of failure?
  • How to determine whether a project succeeded or failed?
  • How to measure the progress of a project?
  • 10 signs that your project is in danger.
  • From “Mission Impossible” to “Mission Accomplished”
  • Learning from failure.

Now that I have blown my horn and done my selfish promotion, let’s focus on the motivation behind this first article. The question that shocked me in this conversation was:  Do projects really fail or do they just disappoint?

At first sight, this question seems harmless but it brought many questions to my attention:

  • What is the motivation to diminish the importance of a project failure?
  • Will threats to the project be noticed ahead of time?
  • When questioned by the CEO regarding the progress of the project, will this project manager tell the truth or find endless excuses to justify the lack of progress?
  • Is feeling better about ourselves more important than delivering the project?

The society has been conditioning us that failing is acceptable. We give consolation prizes to losers for their effort, participation prizes to attendees, awards to players who lost the most units in computer games. For my non Canadian folks, since 1999, in hockey, we give 1 point to the team who lost in overtime for managing to survive this far. What is the difference between losing the game with 5 seconds to go during regular time and losing within 5 seconds of overtime? Really, none. In both cases, the team lost the game. However, the team that lost in overtime feels much better because they managed to get 1 point which helps them maintain their ranking. How does this motivates players to excel? Standards should be raised, not lowered.

From a human resources perspective, I can see some reasons that may tempt us to diminish the importance of failure. A company invests a lot of resources in recruiting competent employees. Getting them up to speed, maintaining high motivation and productivity levels, teaching them how their business works. Because of these factors, when we are faced with issues, we decide to tone them down in order to protect the investment. We don’t want to hurt anyone’s feelings in fear of losing our employees. Bottom line: we want them to stay engaged no matter what value they generate.

Failure leaves a bitter taste in your mouth. It leads to questions, doubts about your ability and ultimately guilt. It’s a very unpleasant feeling and we don’t like to put anyone in this situation. What most people fail to see is that failure is an opportunity to learn. If you are honest with yourself and coworkers, and try to understand what lead to this situation trough deep questioning, you will see that it can be a rewarding learning process. Before you can reap the reward, you have to first admit that there is an issue.

In this case, diminishing the importance of failure by using softer terms lowers the value of the experience we can gain from this situation. It also sends the the following message to our peers:

  • It’s OK. You did your best.
  • You will have another chance tomorrow with another project.
  • It’s not your fault, we will do better next time.

By doing so, we make failure more acceptable to us and to our peers. This is a very slippery slope. Once you start accepting the presence of 1, 2, 3 disappointments in your project, you condition yourself to their presence and you are heading much faster than you think towards failure.

Telling the CEO of a company that his/her financial and credibility loss is a simple deception is like telling the parents of a child that failing the school year is a minor inconvenience.

You can build on small wins to climb a mountain, but you can also tumble downhill with small disappointments. It always starts with small steps.