Tag Archives: key to project success

Risk #2: Project failure

The second risk listed in the Six Key Risks a CIO Must Avoid post is

Project failure occupies a very high place in my list of risks, , , right alongside the IT – Business disconnect. The reason is that an IT organization builds credibility by delivering projects successfully.

If you can’t “do what you say you will do”, , , in other words, deliver projects successfully, , , then you won’t be credible.

This means you have to complete projects on time, within budget, and meet the clients expectations of what you deliver (also known as delivering the expected value or benefits), , , three key ingredients for success.

Studies and surveys point out every year that IT projects have a high level of failure in most companies. It’s time to fix this problem and start building a track record that shows your clients you, “do what you say you will do”.

There are many reasons a project can fail, but I believe most project failures are caused by a few things we do, , , or fail to do, , , such as:

  • Fail to define clear goals and objectives
  • Fail to quantify the specific deliverables
  • Fail to gain agreement from the Project Sponsor on the defined objectives and deliverables

I call these three bullet points the “front end” work. Most IT employees (both managers and technical staff) have two personality traits that works against them in this area.

The first is that over 70% of us are shy and introverted. What this means is that we don’t really like communicating outside our inner circle, , , and clients are definitely outside that circle as you can see in the graphic below.

We may be “the life of the party” with our inner circle groups, but most IT employees tend to be much more reserved and shy in social situations with people outside that circle, , , we don’t communicate as well with groups outside our inner circle.

The second part that causes us to fail to clearly define the project is that 85% of us have a high sense of urgency so we want to start the work as quickly as possible, complete it, and then move on to the next project.

These two personality combinations can be “hazardous to your health” because what happens is that all too often we start working on projects before we have established specifics of what the project should achieve and what we have to deliver to be successful. Here is a key point to keep in mind, , ,

If you don’t identify the goal and quantify the specific deliverable
then there is no way you can complete a project successfully.

There are other contributors to project failure. Conquer the bullet points below and the odds of a successful project go way up:

  • Failing to put buffer into your scheduled completion of project tasks
  • Failing to put buffer into your project budget

 Projects tend to take longer and cost more
than you think they will

  • Failing to identify bottlenecks and eliminating them early
  • Failing to start working on tasks early enough to complete them on time

IT employees tend to procrastinate

  • Failing to prevent “scope creep”

Scope creep is where a project task was estimated to take 8 hours, but discussions with the client and others identify additional things that can be done to make the project “even better”. Before we know it, our 8-hour task is now 20 hours.

The biggest culprit in creating scope creep is our own IT people, , , not the client like you might want to think. Our people are smart, creative, and conscientious, , , they want to do a good job. So, they work with the client on an issue to complete their task and come up with great ideas to make things even better, , ,  before you know it the client wants more than what we originally committed to.

Coach your employees to prevent scope creep

With today’s project management methodologies, tools, and training there is every reason any IT organization should be able to improve upon its project success track record. When you do, your credibility improves and that leads to success as a CIO.

Need help? Take a look at IT Project Management: a practical approach

Project scope creep is going to get you

Do you know what “project scope creep” is?

Who do you think are the main cause of scope creep in your company?

Scope creep happens after you define the scope and deliverable of a project and make a commitment to deliver it. As your team works on the project, over time you discover your client’s expectations of what you will deliver has increased, , , in some cases quite substantially more than what the original project scope was defined to be.

Here is an example. Your original project to develop a new software feature was going to take 300 hours but 60 days into the project the client thinks you are going to develop functionality that will probably take 500 hours, , , your project has mysteriously grown by 40%.

As a result, your project will not be successful, , , you will either deliver less than expected or you will complete the project much later than expected.

Why did this happen and what caused this huge increase in scope, , , better yet, who caused it?

The phenomena of scope creep comes back to “who caused it”. Most think the client is the culprit.

It’s usually not the case, , , most of the time scope creep is caused by your own IT people. That’s right, , , we are the primary cause of scope creep. It is like “shooting ourselves in the foot”.

Here is what happens. Your people, in this case programmers and business analysts, are very bright and conscientious people. They want to do a good job for your clients.

As they begin working on a software feature enhancement to address a client issue, they think of things that could make the product even better, , , little things, mind you, , , but great ideas that will help the client beyond the initial scope of what we originally agreed to do.

Before you know it, the client is all excited about what he is seeing and hearing about his new software feature. As parts of the code are completed, more discussions take place because the programmer and business analyst identify additional things that can be done to improve the situation, , , all good things.

The problem is that these “good things” add work to the project and will make the project run longer and cost more than originally planned.

In many cases, these discussions take place in the background and the project manager is not even aware he is literally being set up for failure, , , albeit unintentionally and more of people trying to do good things for the client.

Coach your employees and teach them about scope creep. You want them to be creative and to come up with good ideas, , , you just need them to bring these ideas to the project manager first to discuss them, , , not to get the client all excited and have his expectations get out of line with what has been committed to.

If the idea has value, we will take it to the client together to evaluate the situation. If it has enough value to change the scope of the project, we will do it in a way that will manage the client’s expectations as to delivery date, cost, etc.

Teach your employees about scope creep and ensure they understand there are only two people who can add additional scope to a project, , , the project sponsor or the project manager. All good ideas need to go through one of these two people.

Projects have to be managed and one of the elements of project management is to manage scope creep.