Are your IT projects late, messy and expensive?

How to become a successful project manager by applying “the secret of the ages”

Software development was once the domain of the academically inclined elite and "they" were consistently forgiven for not meeting originally agreed deadlines, but this level of forgiveness is no longer acceptable or necessary. The delivery of software is late for the same reasons as any other project requiring people, planning and persistence.

Instead of focusing on the delicate human relationships that evolve during the software development process, new project management systems, with sophisticated acronyms (and elaborate training seminars) appear on a regular basis to provide new (and improved) features and benefits for the computer masses.

Enthusiastic followers of the latest time management solutions cluster together on the internet and in expensive training rooms to share their success stories and to learn the new secrets, only to discover that the new methodology did not guarantee an "on time" delivery and their projects are still being delivered late, albeit well documented.

There are numerous reasons why projects "go off the rails" and most of them have been around for longer than the IT industry. To suggest that this article contains a complete list of issues and solutions would be foolish, arrogant and somewhat dangerous.

However, I believe there is a common thread and a pathway to improved results.

Project: Original Estimation

There is no doubt that a portion of the blame has to go the original estimator. Unrealistic timeframes are presented to the customer for reasons of inexperience, ego or to satisfy a hidden agenda.

Why does this happen?

  1. A business analyst or salesperson owner keen to make a good first impression with the customer (and/or his/her manager) will agree on a completion date that looks impressive, but is most likely unachievable.
  2. A salesperson desperate to win the business will underbid the delivery time to get the contract, then hand the problem over to the development team.
  3. A business owner in need of cash to continue trading will pitch a fast delivery to win the business and to secure an early confirmation deposit from the customer.

Project: Defining Requirements

This should be a relatively simple, enjoyable part of the process, for a trained IT professional, but it is still the underlying reason for many software development projects to "slip outside the timeline". It is also one of the most critical parts of the process, yet repeatedly it is lacking in depth and does not reflect a true understanding of the customer's needs.

Why does this happen?

  1. People do not ask enough questions.They are afraid of rejection, looking stupid, being a nuisance or perhaps they do not know what/how to ask. The result is scope-creep (a wonderful expression for "it is going to take longer than we originally thought") and the blame-game (the client did not clearly explain the requirements versus the business analyst did not listen properly).
  2. People do not listen to the answers. Asking questions is only effective when you actually "listen" to the answers and take the time to make sure you understand. It is likely that the customer is not computer literate, from a software development viewpoint, so it is also likely that he/she will not understand why these questions are important, and therefore does not fully comprehend how best to answer them.
  3. People do not clarify the answers. Human relationships are complex even at a one-on-one level (many misunderstandings occur everyday in the home) so when you compound the potential for miscommunication by throwing numerous players into the "system requirements arena" and add that to our basic need to be liked/respected (refer point 1), then customer needs can easily slip through the specification.

Project: Development Team

A theory often suggested is that all software developers are optimists and will always give you an unrealistic answer to "when will the program be finished?" There is some truth in this idea, but it is not the complete answer re "why do programmers often say it is almost complete?", when it becomes apparent many days later, that it is not!

Why does this happen?

  1. Unexpected events. The world of software development includes many hidden passageways, unknown compatibility issues and incredibly annoying glitches. At the time the question was asked, the programmer had not yet encountered these obstacles, so the timeframe given was thought to be correct.
  2. Inexperience. Programmers can become quite proficient at a very young age and are often placed in senior roles beyond their wisdom (knowledge = books and computers, wisdom = mistakes / time / lessons learnt), so their answer is sometimes based purely on information and not tempered by reality.
  3. Optimism and fear. People want to be liked and to be successful. A programmer may provide an impossible timeframe because he/she is too optimistic, or because they are afraid of looking bad and letting the team down, or because they are terrified of their superior. Some managers still believe in ruling with an iron fist, and while this works for some personalities, it can also shatter the confidence of a programmer and cause them to say whatever they feel the other person wants to hear.

Project: Common Sense and Transparency

The success of any project requires common sense business planning, the ability to ask questions (and get open and honest answers) and the willingness to be transparent with team members and the customer. All too often people become embroiled in methodologies and finger pointing, and lose sight of the original objective.

Why does this happen?

  1. Fear. Once again, much of this stems from our desire to be liked and to be successful. To suggest that each party should openly share information and talk through questions and concerns is more difficult than it would first appear. Instead of "fronting up" on a regular basis, the parties involved often operate behind hidden agendas and use carefully crafted documentation to shift the blame and accountability.
  2. Lack of focus on the relationship. No matter how many contracts are signed, if the business relationship breaks down, then typically the project breaks down. The relationship must be high priority and needs to be nurtured and protected throughout the life of the project, and into the foreseeable future.
  3. Inexperience. Allowing the development team to drive the project from a pure technology point of view, rather than a human relationship standpoint is a recipe for disaster. It is too easy for the programmers to get distracted by the latest developments in software, hardware, gadgets and optimisation techniques. The project needs a powerful point of contact from both parties who can bring common sense, real life experience and valid interpretation to the communication flow.

Project: Solutions

Make sure you have competent IT people with great relationship skills working with your customers. Expect your development team to give you optimistic timeframes. Be open and transparent in your communications with customers and your internal team. Use the telephone and face-to-face meetings to communicate rather than emails and text. Admit mistakes quickly and ask more questions, especially during the business analysis phase. Take time away from the project to be with your family and friends, and have fun!

Suggested Reading

Instead of "only" reading computer books, attending computer seminars and searching for more information on technology, I highly recommend adding relationship and personality books to your portfolio including:
  1. How to win friends and influence people, Dale Carnegie
  2. Personality plus, Florence Littauer
  3. Hug your customers, Jack Mitchell

Keith Lightfoot is the account manager for Wired Internet Group Ltd, a New Zealand organisation specialising in IT Resource and Website Development. He is also an author and professional speaker at business conferences.

Join the newsletter!

Error: Please check your email address.
Show Comments
[]