5 Principles for Reducing IT Project Failure

Discussions

News: 5 Principles for Reducing IT Project Failure

  1. As a developer in any company, large or small, your reputation is your biggest asset – you want your projects to be in that successful 8% group. If your IT projects are failing, then you are not going to win the market share you need to compete in that $514.5 billion IT market.

    The following 5 principles lay out steps to make sure that your software development projects are completed on time, and on budget, successfully. Read them, learn them, know them, teach them and then make them stick. 

    1. Communicate: If everyone involved in your IT project doesn’t know what they’re working on, when it’s due, how to get it done and who the audience is, how can you possibly expect your project to succeed? All of the other steps rely on your communication. Expectations, goals, resources, deadlines, priorities, reports and budgets all need to be available to your team so that they can do their jobs properly.  Tools like web-conferencing make it possible for your developer in Hyderabad to share his screen with you in New York, to demonstrate how to recreate major bugs. 

    2. Consolidate: We’re talking about information and tasks. Think about your typical day and how often you stop in the middle of one task to do something else; be honest.  How much time do you spend looking for one email, out of the hundreds in your in-box? Searching for files on your hard drive?  Opening files to find the most recent version or worse yet, working off of an old file version? Writing reports?  Almost every developer can improve his process, cut down on tasks and put data within easy reach, but it isn’t easy and will require changes. 

    3. Prioritize: Issues come in, bugs are discovered, and new features are conceived of every day. Every item won’t be crucial to fulfilling business goals, but your team has no way of concretely knowing which tasks are most important unless someone in management tells them.  Assigning priority tells your team how important each issue is.  Assigning priority and enforcing it, whenever any task or issue is assigned, will make your team work more efficiently. 

    4. Requirements: In ALM and your SDLC, before you can do anything else, you need to identify, prioritize and agree on application (and project) requirements. Your requirements are the items that your application or project needs to include in order to meet your business goals. Once these basic steps are handled, they need to be communicated back to all parties including development and business management. Requirements management is continuous throughout a project; and poor requirements management can lead to all sorts of delays and added costs. 

    5. Manage Time: It’s up to you to take the first step in setting reasonable deadlines and milestones for your team throughout the project. The key word here is reasonable. There are many available tools for tracking how long it takes to do tasks. If you use these tools on every development project that you take on, after a short time you’ll have an estimate of how long these tasks typically take to complete. Set these milestones into your project timeline and CHECK IN!  As each milestone is completed, you get an emerging picture of your project and how it’s meeting business goals.

    Following and adhering to these 5 principles will put you in the elite 8%.  You can’t fake it though; set the standards, find the tools to make them work and then enforce them. Simply giving lip service to these principles won’t put your project in with those rare successful projects.  Make them a part of your daily processes, get your team and other managers involved, and watch how well you meet your deadlines.

    With 10 years of experience working with the world’s largest companies, we’ve seen savings of up to 40% on project costs, by employing these 5 Principles. To learn more on how to make them work for your company, go to www.elementool.com

    Threaded Messages (6)

  2. Wrong Question[ Go to top ]

    I would suggest that rather than trying be part of the 8%, a better solution would be to avoid being part of the 100% of "large" projects altogether.

    Dave Rooney
    Westboro Systems
    http://www.westborosystems.com
  3. Reframing[ Go to top ]

    That's a great way to reframe the question. When the problem is hard to solve, change the problem. :)
  4. Not that I disagree with the message. I'm just not sure why it sounds like you are an employee of elementool? What irks me is the introduction: only 8% of projects are successful? Either success is judged very harshly, or someone's been hitting the drugs a bit hard recently.

    If I assume that stat comes from the CHAOS reports (btw, which states that it is around 32%), Standish is known for inflating the number of failures and understating success.

    ref: Laurenz Eveleens, J. and Verhoef, C. 2010. The Rise and Fall of the Chaos Report Figures. IEEE Softw. 27, 1 (Jan. 2010), 30-36. DOI= http://dx.doi.org/10.1109/MS.2009.154
  5. Failure Rates[ Go to top ]

    I agree that Standish's definition of a failure is suspect.  Windows 95 was over a year late and full of bugs, but it was an unqualified success in terms of sales and market penetration.  Even some outright project cancellations can be considered a success if they save a company time, effort and money because work that wasn't needed wasn't done.

    What I do look at in the Standish reports is the Top 10 list of indicators.  The top 2 have always been Executive Support and Business Involvement, swapping places a number of times since 1995.  Small projects has always been a success factor as well, and I think Cameron's assertion that 8% of "large" projects fail is actually pretty close to reality.  You can deliver large systems as a series of smaller projects, but there's a ton of risk involved with a large, big bang approach to delivering a large system.

    Dave Rooney
    Westboro Systems
    http://www.westborosystems.com
  6. Need I say more?
  7. Another advice: don't pay thousands of buck to so called "consultants" which charge insane amounts of money to tell you the most obvious things as if they just discovered the wheel. Not even if they use powerpoint slideshows with custom bullets in them.

    Now seriously, was this post ironic or are we back in the 90's?