In my experience as a project manager, unrealistic timelines or schedules are one of the most common reasons for unsuccessful IT project planning. I’ve seen my share of projects fail. In fact, according to the Cranfield School of Management in the UK, 68% of projects are destined for failure. Given this, I’ve often wondered, why do companies continue to let them fail ?
In my first blog of this series of “Why a Good IT Project Plan Drives Success”, I listed unrealistic timelines or schedules as one of the main reasons for project failure.
How do unrealistic schedules come about?
Unrealistic timelines are usually the result of an overly optimistic senior executive declaring “We must have the best, fastest project results within the next 2 weeks”. (Of course, it is not always a two week window, but I’m sure you get the idea.) Usually this is said because of various business reasons and often based on unconfirmed assumptions of the scope of the project.
Accurate time estimation is a crucial skill in project management. To get a good estimate you have to understand what’s required first. As I stated in my previous blog, project scope drives project cost and time and there is always something omitted or underestimated during the scope definition phase.
During the planning stages, you can estimate timelines yourself, ask specific project team members to contribute, or brainstorm them as a group. Working with your team members to develop project timelines will help to confirm any assumptions that may have been made in regards to the scope of the project. Focus with your team on estimating the time needed for each task rather than for the project as a whole. By involving them, they’ll also take on greater ownership of the time estimates they come up with.
Always assume that your timelines are too demanding. Ask for more time in your projects upfront. Especially in the requirements stage – it is important to spend time documenting exactly what the user wants instead of discovering a misalignment later in the project.
When all is said and done, assume that your resources will only be productive for 80% of the time. The 20% cushion will give the project team an opportunity, should the need arise, to catch up without having to send people over the edge. This cushion will increase the probability of delivering on-time and on-budget and add to the IT project planning success.
I am sure many project teams have experienced being pushed to the limit and still unable to meet a stated timeline and as a result feeling defeated. The failure usually is not as a result of the team’s effort but rather someone, during the planning stage, underestimating the amount of work needed to complete the project.
As a project manager, when you realize that there are unrealistic timelines (and it happens often), you need to sit back and consider the impact on your project and how best to proceed. The usual response is to work longer and harder to meet those unrealistic timelines. However, extended periods of long hours are not sustainable or recommended. A long period of over extending has a negative long term effect on the people and therefore on the work environment and productivity suffers. Working “tired brains” simply does not work and usually results in poor design and software defects.
As I mentioned in my previous blogs, planning and delivering IT projects is a team effort and you need to keep in mind that the real assets are your team members. Over working the team for a project with unrealistic time lines will not only jeopardize the success of one project, it will cause problems for subsequent projects (but that’s a topic for another blog).
At the end of the day, projects should not have unrealistic schedules. Unfortunately, in most cases, the mindset around project delivery times is usually out of alignment with reality. We need to focus on realistic schedules to build small, incremental successes in project deliveries. Instead, people are asking for massive requirements in ever shorter time frames.
In my upcoming blog I will address Lack of Adequate Resources and its relevance to IT project planning success.