Wednesday, 23 June 2010 00:00

Do You Know Where Your IT Projects Are? Part 4.

Written by

In this last of four articles, Yogi Schulz completes his description of the 12 signs of impending IT project doom that are visible months before catastrophe strikes.

Change Management

Good – I lead the project team in addressing the introduction of new business processes and their impact on staff.  For example, the project team has been coaching business leaders in how to introduce and effect the required change to the order fulfillment process.

Bad - The project team is not introducing new business processes, despite my encouragement as project manager, to place more emphasis on this topic.  For example, the project team is totally absorbed in software development and data migration.  No resources and capacity are available to think about how the new system will change long-standing business processes.

Ugly - The project team doesn’t believe change management is required.  The project team believes change management will be handled informally by the business and is not part of the project scope.  For example, because the project team does not include individuals with the requisite change management experience, the team has rather flippantly said to the business:  You handle the change management piece.

The Fix

  • Recognize that almost every IT project introduces business process changes.
  • Insist that change management is in scope for the project to help the organization make the change.
  • Successful project managers ensure the project team competently executes change management tasks.

Project Technology

Good - The project consistently uses a short list of technologies.  I can conceptually describe the technology.  For example, the technology being used is .NET and SQL*Server.

Bad - The project uses an extensive and changing list of technologies.  Initially it was Microsoft; some months later it’s Java and more recently something called LAMP is being discussed.  For example, the project changed from .NET/SQL*Server to LAMP claiming shorter software development times.

Ugly – I observe the project team using lots of technology buzzwords in discussions. It’s not clear what technologies the project is actually using.  I’ve seen a flashy demo but I’m not sure how that delivers business value.  For example, some of the project team is using Java for the database layer, others are using .NET for the application layer and a few are using PHP for the presentation layer.  It appears the developers are using the tools they’re most comfortable with or the tools they want to explore.

The Fix

  • Select and stay with a set of technologies for the project.  Avoid revisiting technology selection as new glitzy products are announced.
  • Pick technologies where the IT organization demonstrates expertise and experience.
  • Successful project managers assertively insist that project team members stick with the selected technology.

Conclusions

For each of the characteristics, watch out for the signs that lead to project catastrophe and take action to ensure project success.

Recommendations

Address Project Success Factors in the Project Charter

As project manager, describe how you expect to execute the project in the project charter for discussion with the project sponsor and other members of the project steering committee.  For example, describe your project organization, status reporting plan and technology.

Use the draft project charter to drive discussions within the project team and with various stakeholders to achieve consensus on these key success factors.

Recognize Common Project Factors that Lead to Success or Failure

As project manager, keep a sharp lookout for these project failure factors.  Encourage the project team to draw the emergence of a project failure factor to your attention.  For example, when a project steering committee member resigns and no evidence of action to replace that person is apparent, what do you do?  Make a recommendation to the project sponsor.

Take Corrective Action when a Project Failure Factor Looms

By taking corrective action when project failure factors loom, you are ensuring that your organization achieves business value from its investments in the IT project.  You will also avoid the destructive finger pointing that is a consequence of most unsuccessful IT projects.  For example, what do you do when your project sponsor is promoted, transferred or fired?  Do you just meander along on your own?  No, as project manager you recommend to the project steering committee who will be the interim project sponsor and who the potential candidates for a new project sponsor are.

Don’t forget to leave your comments below


Yogi Schulz is a partner at Corvelle Consulting.  The firm specializes in project management and information technology related management consulting. Mr. Schulz holds a B.Com. from The University of Calgary, is a member of CIPS and holds its ISP designation. He has presented at many conferences, writes for the Microsoft web site and appears on CBC’s Wild Rose Forum. Mr.Schulz can be reached at YogiSchulz@corvelle.com.

References:
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-1.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-2.html
http://www.projecttimes.com/articles/do-you-know-where-your-it-projects-are-part-3.html

Read 8094 times

© ProjectTimes.com 2017

macgregor logo white web