AIX > Tips & Techniques > Application Development

Project Plan Creation: Collaboration Beats Dictatorship


I’ve created lots of project plans; all were to some degree collaborative. I’ve also worked in projects laid out by a “lone-wolf’ project planner. Without question, the most effective, comprehensive, accurate and thorough project plans are collaborative. Similarly, the most successful, productive and fun projects are collaborative. I dread lone-wolf project plans, not just because it’s a recipe for disaster, but it’s also inferior. Sometimes this lone-wolf mentality is an ego-based need for total control, but often it’s the result of systemic, organizational structure.

I recently worked with an organization who instituted project management that was effectively disassociated from project participants. IT project members were excluded from project plan creation except for rare occasions when we were given a woefully-inadequate one to two hours to formulate an estimate. Sometimes senior members of IT would provide input. Time estimates were formulated for project phases rather than specific tasks. Projections were often made before a plan, and no detailed plan or project analysis was performed. Project status and reporting were online, excluding project participants from status meetings.

In virtually every way, project management and tracking was divorced from project participation. Completion dates were dictated, rather than being a project plan byproduct; needless to say, project management wasn’t very effective.

Collaboration vs. Separation

An initial project plan should be an exercise in consensus, not a tool for setting deadlines. Deadlines have to be met, but they shouldn’t influence the construction of a plan until it’s complete. Then resources can be shuffled, project phases trimmed or cut and the plan can be tailored to meet objectives. Intimidation or threats should be avoided; it should be an expression of what the team believes is possible.

A good project plan is a realistic estimation; a bad project plan is an expression of what’s expected. A collaborated project plan technique should include:

  • A first-cut plan formulated by one or a few technically or process-skilled individuals. Transcribing and integrating installation tasks from product installation guides, previous project plans, project plan templates and other sources is a cut-and-paste process. Installation information gathering from various sources is straightforward.
  • Individuals assigned to project phases (e.g., install CICS, develop procedures, design application screens, etc.)
  • Completed task description and sequencing (linking tasks in the order they must be performed)
  • Assigned people to review and tailor phases
  • An updated plan with phase-reviewer input
  • Time estimates produced by individuals for their tasks and integrated into the plan. A “fudge factor” is added to account for unanticipated tasks and problems. My fudge factor is 50 percent.
  • Individuals understanding responsibilities for them and others

Bottoms Up vs. Top Down

Project plans containing only high-level tasks, deadlines and total time estimates are inaccurate and naively misconstrued. As the adage says, the devil is in the details. Ironically, so is the truth. It’s hard to overstate the importance of attention to detail during project plan construction. Many project aspects only become apparent as specifics emerge.

While it’s true a project plan can contain too much detail, most bad plans don’t contain enough. Usually that’s because the creator had limited technical, application, system or process skills. Digging into detail has numerous advantages, including:

  • The more granular the tasks, the better the time estimation. It’s much easier to estimate how long it takes to run a job or populate a file than to estimate how long it takes to install a product. Summing up product installation tasks produces a more accurate estimate.
  • Identifying individual tasks makes it less likely that something will be overlooked
  • Research involved in identifying individual tasks makes it more likely that any showstoppers (e.g., incompatibilities, standards conflicts, required new function, etc.) will be identified and accommodated
  • Tasks that would have otherwise been overlooked will be identified and included

Motivational vs. Dictatorial

To use a sports analogy, a good project manager is a coach, not a boss. Most project participants don’t report— organizationally speaking—to that person. That was usually the case in projects I managed, because I was an outside consultant. I had no direct authority over many participants; that’s usually true whether it’s an internal or combined staff project.

Regardless of staff makeup, a collaborative project plan can be a powerful motivator because:

  • The project plan becomes their project plan, not someone else’s plan. It provides a sense of ownership.
  • They have some control over their part of the project
  • Since they’ve been the primary authors of their project components, they feel responsibility for them
  • By participating in status meetings and similar activities, a sense of teamwork develops, and members often help each other meet objectives

Analysis and Adjustment vs. Blame Game

A collaborative project plan is constantly evolving, changing and adaptive. A dictatorial project plan is static and rarely changing because the plan is designed to establish authority and prescribe desired results. It’s a method of enforcement and doesn’t reflect reality. Consequently, a static project plan can result in a lot of conflict, including that:

  • Since it’s virtually certain a static plan is not going to proceed as stated, a lot of finger-pointing goes on. Plan creators don’t want to admit mistakes; plan participants don’t feel responsible for something forced on them.
  • While a collaborative plan is dynamic and adaptive, it does require wise, informed oversight. Changes to the plan need evaluation as to reasonableness and authenticity. It can’t be an excuse for mistakes and omissions.
  • Key management shouldn’t depend on reports to keep a finger on the project’s pulse, although those reports may be useful. Participation in weekly status meetings is the best way to monitor a project; interaction and discussion is the best form of communication.

Team Effort Critical

Like any aspect of a successful project, an effective plan is a byproduct of team effort. When those who do the work also build the plan, it’s more complete, accurate and usable. Staff members who assist in planning are more likely to embrace and take ownership of the plan. Team spirit is built, and confidence in project success is fortified. Conflict is reduced and motivation enhanced with collaborative planning, and the final plan is easier to tailor and adjust as the project progresses. Project plan creation by someone who knows project management but not the project, dictating results without project analysis, is a recipe for disaster.

More in the Series

Tenth in my “how-not-to” series looks at the importance of a collaboration and the destructiveness of dictatorship when creating a project plan, 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.

The sixth article, “Set Realistic Expectations to Ensure Project’s Success,” can be found here.

The seventh article, “Leading Edge, or Bleeding Edge?” can be found here.

The eighth article, “IT Upper Management: Friend or Foe,” can be found here.

The ninth article, “The Project Plan: Key to the Kingdom,” can be found here.

Jim Schesvold can be reached at jschesvold@mainframehelp.com.



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

Advertisement

Advertisement

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