AIX > Tips & Techniques > Application Development

Set Realistic Expectations to Ensure Project’s Success

For the past 20 years, characterizing and scoping IT projects has been a big deal with me. Especially when I managed an IT consulting firm and consulted for it, accurate project sizing and delineation was vital; if I got it wrong, I paid from my own pocket. I learned fixed-price contracts could be disastrous, especially if the up-front work of defining, documenting and researching wasn’t thorough and comprehensive.

Every project was different, every client’s system was different, and there were “gotchas” that couldn’t be foreseen; it was impossible to precisely determine all the pieces of a project. The more time and effort spent in scoping a project, the better the outcome, and the more project participants were involved, the more effective and efficient they were. Rigorous, meticulous, scrupulous due diligence pays huge dividends.

Drilling Deep

Think I feel strongly about this? You’re right, thanks to the pain I endured from insufficient fact-finding and examination. It’s how I evolved the rule: Drill deep and add 50 percent for the gotchas.

Drilling deep means exhaustive project and application research and analysis. The object is to prepare every project member for his or her part, to get the estimate right and to insure success.

Kickoff Meeting

The kickoff meeting is the pivotal event in drilling deep. Whenever I got a moderate- to large-sized project, or when I was working with a new client, a kickoff meeting was a must. Everyone involved in the project at any level should participate in this meeting, including:

  • Upper management. While they may not attend the entire meeting, upper management (e.g., directors, vice presidents) participation in a kickoff meeting can be of great value. Often they will make opening comments, describe their objectives and express their support. It’s a great way to get to know everyone, and can be an asset when the going gets tough.
  • Direct management. These managers are involved in project management, project tracking, decisions, staff assignments and crisis management. They need to be informed in depth. A kickoff meeting does that.
  • Programmers/technicians and/or consultants. These are the ones who do most of the work, so the kickoff meeting is of greatest value to them.
  • Operations staff. Especially in the case of systems projects (e.g., an operating system upgrade), the project can have an impact on their job, especially procedures.
  • End users. These are the people who know the business process best, and they need to pass on both their expertise and requirements.

Project Plan

  • The project plan is the vehicle where drilling deep is done; it should cover technical, usability and other aspects. It is the most valuable product of a kickoff meeting, the blueprint for project definition and tracking, and it’s both the consequence of drilling deep and the catalyst for drilling even deeper.
  • While much of a kickoff meeting is spent on the project plan, that’s not where the plan begins. I would always create an initial project plan prior to the meeting, a starting point that saved a lot of time. This initial plan was a blend of existing templates and a lot of material gathered via previous interviews or from product installation documentation.
  • The kickoff meeting is not where a project plan is completed, either. A plethora of research tasks are identified and/or initiated from discussions during the meeting and the project plan review. The objective of this review is as much to identify new tasks or expand on existing ones as it is to discuss existing ones.
  • Demonstrations and walkthroughs, which may occur during the meeting or after, often result in many project tasks, and the doers gain a much greater understanding of expectations.


Appoint a project plan secretary prior to the kickoff meeting to update the project plan, create project-related documentation and organize project and change-control documentation. Management updates may also be a necessity. A keeper of the plan is invaluable.

Change Control

  • Change control procedures are defined during the kickoff meeting.
  • Changes need to be integrated into the project plan as they occur. A decision of whether they’re in scope has to be made. If not in scope, it needs to be priced or eliminated.

Post-Kickoff Drilling

  • A kickoff meeting may generate as much as or more work as gets accomplished during the meeting. Follow-ups are identified, and each should be assigned to an individual or team and added to the project plan. How does this work? Will we need to make a change here because of what is happening there? As each follow-up gets completed, new tasks are added in the plan.
  • Additional project meetings will invariably be required, because follow-up results need to be shared with the project team so each person can determine whether the impact on his/her part of the project.
  • Follow-ups may generate new follow-ups; the process of drilling deep is iterative. A project plan is a living entity. It evolves and changes during a project.
  • As the project gets started, drilling may continue in parallel both with ongoing investigations and unanticipated snags. Regardless of how hard one may try, unexpected surprises will occur during development and testing; this necessitates more research and analysis. This isn’t a surprise; it’s the nature of the process.
  • Demonstrations and/or walkthroughs will generate new follow-ups or tasks, and provide skills transfer.
  • Weekly project reviews are a necessity, and the project plan gets updated based on them.

Add 50 Percent

I found that 50 percent, after the first round of follow-ups, was a pretty dependable value to add to initial hours, resulting in a reasonably reliable estimate of both total person hours and total days to complete a project (assuming a 6.5 hour workday). Initial hours-per-task assignments were based on past experience and assignee input. I never hit it on the head, but I was usually within 10 percent. I’ve found it’s better to be too high than too low, because clients or users get much more agitated when a project runs longer than expected. You have to account for the gotchas. They’re virtually certain in any project.

I’ve worked with and for clients who didn’t take project planning, research and analysis seriously, and the results ranged from poor to disastrous. Drilling as deep as possible is the key to good project planning. One company I worked with never asked project participants to a kickoff meeting, never drilled deep, never added time for the gotchas and rarely accepted input on hourly estimates. They also had a dismal record for project completion and success. Surprise, surprise? Not really.

More in the Series

Sixth in my “how-not-to” series looks at the need for accurate and thorough project research, analysis, and estimation, and is based on my more than 35 years of work in mainframe IT, reviewing mistakes I’ve seen or participated in and helping others to avoid them.

My first article, “End Users: A Programmer’s Best Friend and Worst Enemy,” can be found here.

The second article, “Demystifying The Myth Of Measuring Programmers With Metrics” can be found here.

The third article, “Demystifying The Myth Of Multitasking” can be found here.

The fourth article, “Demystifying The Myth Of Sweatshop Mentality” can be found here.

The fifth article, “Demystifying The Myth That Generalists Outperform Specialists” can be found here.

Jim Schesvold can be reached at

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters