Posts Tagged ‘project management’

The Technology Project Plan

Professional Development | Posted by Tom Carpenter
Apr 13 2009

After teaching Information Technology Project Management more than 100 times, I must say that the most common feedback I get is related to the technology project plan. Students, who are aspiring project managers and senior project managers, frequently state that their organizations do not grant them enough time to create effective technology project plans. In this post, I’ll suggest three things that you may find helpful.

First, a question. Why do so many organizations expect IT engineers and architects to develop complex solutions without granting them the time required to plan well? I think it boils down to a simple answer: they don’t understand just how complex IT projects can be. The assumption seems to be that technology is plug-and-play and it all just works together. This thinking may be the result of our poor communications, but it must be remedied. Hence, my first suggestion:

Begin to communicate the complexity of IT solutions.

You may find that you are granted more time to create the technology project plan if you help the sponsor understand how complex the technology really is. For example, you may say something like, "Did you know that there are more than 2300 bricks in a 16 x 28 foot wall? Imagine the planning that goes into choosing all the right bricks and materials needed for an entire two-story colonial home. The application we’re developing is a lot like that. It will have more than 46,000 lines of code in the end. If we make cuts on the planning, the end result will only suffer for it." This analogy brings me to my next suggestion:

Draw on past failures.

Now that’s something you don’t hear every day; however, it’s very important. Many IT project failures can be directly linked to poor planning. Reminding the sponsor of this reality can help you buy the needed planning time for your next project. You can also encourage the creation of a better technology project plan by following this recommendation:

Point out the cost of not planning.

This suggestion may sound similar to the previous one, but we’re actually going to focus on a different perspective. Rather than drawing on past failures, we’ll point out the rough order of magnitude (ROM) estimate for the project in question. Imagine the ROM estimate is between 1.2 million and 1.5 million dollars. Choosing the wrong hardware or software early on, in such a large project, can easily cost over $100K. Point this out while requesting time for planning; however, keep this in mind: if you use this technique and still select the wrong hardware or software after extensive planning, you may have ruined your project management career in that organization.

These three solutions will help you gain the needed planning time, but you will need to ensure that you have selected trusted team members who can help you create an accurate technology project plan. Assuming you have, you’re now ready for project management success.

Post to Twitter Tweet This Post

Project Management Methodology: Do you have one?

IT Theory | Posted by Tom Carpenter
Mar 10 2009

A methodology of project management or a project management methodology can simply be defined as the method by which you manage a project. Everyone uses a project management methodology, it’s just that many project managers change their methodology on each project. Here’s the question I’d like to answer: What’s the benefit of a standardized project management methodology in the first place?

I would suggest that a standardized methodology provides the following four primary benefits:

  • Collective knowledge
  • Greater predictability
  • Capability maturity
  • Reduced stress

 

Now, I know that last one is hard to swallow since many people think of a project management methodology as a source of added stress via the requirement of added documentation; however, I would suggest that a well-documented methodology reduces stress because you never have to ask, "What do I do next?" You have inputs, processes and outputs. The methodology of project management should indicate the source of the inputs. Next, it should state what you will do with those inputs (the processes). Finally, it will provide you with forms or templates that you fill out as a result of the processes (outputs).

With the last benefit covered first, let’s go back to the first listed benefit: collective knowledge. There are many things in life that we trust. For example, we trust that it really is safer to wear our seatbelts than to drive without them (at least I haven’t done actual research myself). This is collective knowledge. A documented project management methodology provides the same benefits. If you use a template that was created out of experience and education, you will reap the benefits of using that template whether you know it or not. This, in a nutshell, is the benefit of collective knowledge.

The second stated benefit was greater predictability. Since you are using established inputs, processes and outputs, you can predict with greater certainty how your project will go based on how it starts. Additionally, you can look at the project at any point in the lifecycle and make estimates as to the outcome using established and mature processes.

That last statement leads me to the third and final benefit (since I covered stress reduction first): capability maturity. A solid methodology of project management will be maturable. It will include a lessons learned process at the end of the project that may be used to mature or improve the methodology. This increases the "capability" of the project management methodology to meet the needs of your organization.

My suggestion is that you do not start from scratch. You can use PMI best practices as a starting point or another model like The Systems Education Company’s Method 4D methodology. However, no matter the starting point, you will reap these benefits and more if you begin to use a methodology and then mature that methodology over time.

Post to Twitter Tweet This Post