Application Development - Baseline
Home arrow Application Development arrow Active Risk Management: Doing IT Projects Wrong













Renew Your Subscription

Application Development



Active Risk Management: Doing IT Projects Wrong



By Bruce F. Webster

  Table of Contents:
  1. Active Risk Management: Doing IT Projects Wrong
  2. Risk Management: Documenting the Risks

In IT projects, Bruce F. Webster writes, you have to be honest and vocal in pointing out legitimate risks or else your budget, team and client are all going to end up losing the project battle. Being honest about project issues upfront can help win over clients trust and show your team that managing for success begins with a smart, organized approach to risk mitigation.

Rate This Article:
Add This Article To:

Active Risk Management: Doing IT Projects Wrong


( Page 1 of 2 )

IT projects are typically full of risks. There can be many human factors, many external factors, and many unknown factors, all of which can interact in unexpected ways. Because of that, it is critical that you actively identify, track and manage those risks. But to do that means that you have to be willing to stick your neck out, be vocal and point out risks that the business side may not want to address.

Some years back, I was consulting for a client that had several IT projects going on in parallel. My primary task on getting a particular project back on track, but I was also asked to oversee the architectural effort for another project that was just starting up. The client was developing this second project for an outside customer and was in negotiations with the customer regarding both schedule and cost. For simplicity sake, I’ll call this second project “KAID”. 

In early November of that year, I attended the first major KAID project meeting. The program manager for the project – that is, the client employee working directly with the customer – laid out the schedule which he was going to give to the customer: we’d start coding at the start of December, we would finish coding by the start of March, and we would finish testing and deliver the system to the customer by the start of April.

He asked one by one for a show of hands around the table for those who supported that schedule. To my amazement, hand after hand went up around the table from the IT project manager, the senior technical leads, the subject matter experts, and others.

When the PM got to me, I pointedly kept my hand down and said I wouldn’t sign up for the schedule – both because there was no foundation for it and because I saw a number of major risks with the project. The project manager looked a bit startled at my rather firm refusal to “go along,” but then finished his way around the table.



 
 
>>> More Application Development Articles          >>> More By Bruce F. Webster
 


Sponsored Links
  • Get up and running in as quickly as 30 days with BI. Learn how today.

  • FREE Securing Smartphones & Tablets for Dummies Book from Sophos
  • 5 New Technologies That Will Change Enterprise ITAdvertisement
  • Build an IT Infrastructure That Delivers the Future
     
  •  
    FEATURED SPONSORED ARTICLES

    FEATURED SPONSORED VIDEOS

     



    LATEST STORIES


     

     


    Advertisement
    rss graphic
           Baseline Newsletters