Skip to main content

Author: Steve Pieczko

From the Archives: Why You Need a SWAT Team for Failing IT Projects

According to IBM, 60% of projects fail to meet their goals and objectives. KPMG reports that 70% of organizations surveyed have experienced one or more project failures in the past 12 months.

Today organizations with IT budgets typically utilize a Program Management Office (PMO) to assess and report on the health of IT projects. The traditional PMO does a great job of reporting on project financials, project staffing profiles, schedule milestones, plus risks and issues… but they don’t do enough to decrease the percentage of project failures.

To save failing projects, you need a new entity. I call it the Office of Project Resilience (OPR). The OPR would only focus on project execution and team dynamics; it would not include metrics typically used in the PMO. The OPR would have new metrics such team cohesion and resiliency scores.

The OPR might step in when a project is reporting red for more than three weeks. If the current team can’t remedy the situation within this period, then there probably is an undiscovered systemic issue.

Related Article: The Top 3 Causes of Project Failure

Typical activities of the OPR might include assessing the following:

  • Do I have the right heads in the right hats?
  • Is the team working on the right things?
  • Does the team believe that success is achievable?
  • What’s the current emotional state of the team and has it changed from last week?
  • What does the customer think of our team?
  • What’s the probability that we’ll make it?
  • Are there ongoing assessments of the team?
  • Are communications effective?

The OPR needs to have autonomy from the PMO and would handle assessing roles and responsibilities on the project and putting new heads in new hats to reset the path to success. Once the project returns to a green status, the project would return to the jurisdiction of the PMO.

Predictability vs. Resiliency

Successful teams are resilient. But with IT projects, many organizations ignore the issues that influence resiliency. Instead, at the beginning of a project they look for a simple prediction, such as, “How long will this take?”

But the more complex the project, the more likely that won’t go according to plan. Therefore, dealing with surprises requires resiliency. Let me illustrate with a simple example.

If your home water heater broke, you’d call a plumber and perhaps ask, “What do you think it will cost to replace my 40-gallon water heater?” You pick a plumber who offers a low estimate, say $500.

A few hours into the repair, your plumber breaks an old plumbing weld and causes a horrible mess; your basement floor is now flooded, and your carpet is ruined. You no longer care about the plumber’s ability to predict a $500 cost; now you just want him to be resilient enough to stop the flood and bring your house back under control.

If you had been watching the plumber, you might have pointed out the old weld to him. Or you might have noticed that he was rushing. This is the role of OPR: to influence in a positive manner the mindset and actions of teams that are under great pressure.

This article was originally published November 24, 2015

Why are Today’s IT Projects Running at a Three Minute Mile Pace

3MinuteMile1Back in my younger days, I could run a sub-seven minute mile. When I heard about somebody running a five minute mile, I thought “now that’s really fast”.  Today, the world record for the mile run is 3:43:13, set in 1999 by Hicham El Guerrouj from Morocco.

In the eighties, IT projects felt like they moved at the pace of an eight minute mile.  We took the time to write detailed requirements, detailed design documents, thorough project plans, test plans, you name it.  If someone had a new idea or a new process on how to “do it right”, it was implemented.  I recall hour-long meetings on ways to improve processes on projects and conversations around what wasn’t being documented that needed to be documented in case somebody asked the question “where’s that documented?”  We even took the time to write detailed communication plans, which is something that I haven’t seen in a while. 

At some point during my career, upper management started asking the question “can you move the project along faster by adding more people?”  So we would add a few more developers, cut the QA testing cycle and shave off a few weeks on the project schedule.   It began to feel like a six minute mile run. 

Fast-forward to today and it feels like projects are clipping at the pace of a three minute mile. Fast just wasn’t fast enough!  At times, I’ve left work with a splitting headache, a plethora of emails to read when I got home, and pondering if this truly is the current state of IT projects?

Is your project team running a three minute mile?  How do you keep up the pace and train them to run a project marathon or relay race without creating shin splits and total exhaustion? Here are some practical ideas to consider:

1. Create Alignment with the Business

For a project team that’s running at a fast clip, one of the most important things you can do is to make sure that everyone has a clear understanding of the project vision and clear direction on how to get there.  Imagine the project manager tells the project team “we’re having our next meeting in Springfield”.  The majority of the project team (based in Illinois) thinks that the project manager meant Springfield, Illinois. However, there’s one member of the team that used to live in Missouri and he’s thinking the project manager meant Springfield, Missouri.   This analogy, which was recently used in a webinar on the importance of upfront requirements, very clearly illustrates the problems that can develop when a common understanding is missing!

Typically, the beginning phase of every IT project includes a requirements gathering phase where the Business Analyst interviews Subject Matter Experts and documents the feature list which is then handed over to the IT team for estimating.  Depending on the size of the project, the requirements definition phase can take a significant amount of effort to complete.   I’ve found that many projects fail because they simply don’t do a good enough job of capturing the intent of what the business wants to build.  You’ll know that you’ve accurately captured the business intent when the response from the business is “that’s exactly what I asked for! Build it now!” A runaway project is a tell tale sign that the intent wasn’t accurately captured.

Too often, the traditional approach to gathering requirements takes a long time, doesn’t include the right individuals or do a very good job of reaching consensus among the project stakeholders.    Additionally, traditional approaches to requirements may do a good job accurately recording specifications and design, but the requirements often fall short because they do not reflect a shared vision on the organization’s business needs.   This lack of alignment usually produces last minute changes in scope when you’re weeks away from implementation or very early scope changes that occur during the first few weeks of development.  Regardless, a lack of alignment will impact the project schedule and add additional costs to the project, frustrating the project sponsors.

Alignment: Make it more than a buzz word  

True alignment is based on a common vision of success not only between the business and IT but also between the various business stakeholders.  For example, do the CEO, CMO, CIO and CFO all agree on the business objectives of the project? 

 One method to create alignment is to hold facilitated white-boarding sessions that bring together subject matter experts from the business for a walk though of the requirements definition process.  The facilitated sessions are designed to gather input on what needs to be built without anyone saying “it can’t be done”.  At the conclusion of a facilitated requirements gathering session, the business has in a common language that both IT and the business can understand and fully estimate, a full set of documents which convey what needs to be built. 

2. Implement Transparency Across the Project

For many athletes, winning the race is all that matters and for others simply participating in a race may be their goal.  Regardless, the strategy that we take in the race is dependent on our goals so it’s equally important that we make our goals and objectives clear, i.e., transparent.

Jim Collins, author of How the Mighty Fall, notes that project teams on the way down tend to shield those in power from their grim situation.   They’re fearful of penalties and criticism for shining light on the realities. Teams on the way up, however, aren’t afraid to bring forward unpleasant news.  Further, teams on the way down assert strong opinions without facts while teams on the way up bring data, evidence, logic and solid arguments to discussions.    

Transparency can mean different things to different people. However, on a project team that’s implementing new functionality or a new product offering, transparency refers to thoroughly communicating the smallest impacts to the project sponsor.  Too often the project team is put into a corner because they unknowingly accepted risk onto the project without informing everyone about its potential impact.  

How transparent do we need to be?

Consider this: The business analyst is running late by one full day and didn’t complete the final version of the requirements document.  The typical project manager thinks the impact is low and that the team can make up the time. Nothing is communicated to the project stakeholder or upper management.  Assuming that the schedule was already tight and didn’t include a review period or contingency in the project plan, the developers and QA waiting for the finalized requirements document are now off schedule by one full day and will have to make up the lost time.

It’s easy to believe that a few hours are easy to make-up, and so the project manager unknowingly accepted risk onto the project by not communicating a minor one day misstep.   The correct response for even the smallest delay is for the project manager to communicate the impact and present options to the stakeholder. In this situation, for example, this might include requesting that an additional day is added to the schedule.  If contingency was already built into the plan, you might not need to ask for an additional day but communicating the one day slippage is a must. 

The point of implementing transparency is that we often think something small doesn’t have an impact to the project. However, every deviation from the project plan causes an impact somewhere else.  Think of this as the butterfly effect where something that seems to have a very small initial impact can actually produce drastically different outcomes.  The butterfly effect goes like this: A ball placed at the crest of a hill might roll into any of several valleys depending on slight differences in initial position. However, the path that the ball takes based on the initial position could produce drastically different results.  So even if you’re not formally requesting additional time to the project schedule, the project sponsor still needs to understand the most minor impacts and missteps that occur on the project. 

3. Leverage Paired Management

While most people think that running a marathon is an individual sport, many times runners have helpers running alongside them to provide support and motivation.  The same can hold true on project teams…

 Like the Agile concept of paired programming, some of the best run projects that I’ve encountered included project teams with multiple project managers and a clear separation of duties. In these situations, everyone responsible for managing the project felt that the goals were achievable.  Something as simple as splitting up management duties can result in more efficient project managers and a smoothly running project team. 

The role of the project manager is complex.  For example, the project manager typically carries the burden of the project and usually takes the heat when something doesn’t go right.  He/she has to understand the business and technical details of what’s being implemented and many times they wear multiple hats.  The project manager also has to report status to the PMO, the project sponsor, upper management and resolve the day-to-day issues, which alone can be a full-time task.

Just how busy is the project manager?

An important step in running fast paced projects is to assess the workload of the project manager and ensure that he/she is focused on the right things.  Creating an effective project manager begins by separating out their tasks, whenever possible, and asking the question “do the project managers have enough time to focus on what’s really important? Or, is their day filled with so many tasks that they aren’t focusing on the right stuff?”   If you added a second or third project manager to the project would things improve?  Of course, adding too many project managers can also have a negative effect — especially if you involve strong personalities.  In general, try dividing the project manager duties by functional deliverables, internal focus vs.  external focus, or by the team dynamics (i.e., which team members work well together including their involvement with a particular project manager.) While  recommending to upper management to add  more project managers  may raise some eyebrows about the  additional costs, simply ask  whether  the current project manager is  focused on the right things and whether  success is achievable.

4. Cut Out the Noise! 

Imagine how distracted the runner would be if he/she wasn’t able to filter out the noise from the crowd.  The same holds true for a project team – noise creates distractions and lost focus. 

I can’t tell you how many times, late in the project lifecycle, someone says “we need to implement the following functionality or the business won’t sign-off on the system” or “we forgot to include the following feature which is a must-have for go-live”.   Every time I hear stuff like this it gives me a headache and I usually respond with “so tell me what happens if we do nothing?”  

How do you turn down the noise around missing functionality?

Typically, the noise that comes at the end of a large project is the by-product of (1) not creating alignment with the business or (2) not implementing transparency or (3) an overworked project manager.   Had the project reached agreement with the business, implemented transparency and added multiple project managers, the project might not be in a situation where energy is spent defending project noise. 

The typical way to address the non-stop flow of changes is to clearly define the scope and implement a change control process from the beginning with the goal of minimal change requests.  However, before you do this, make sure that everyone has the same understanding and rules for the change control process.  While change control is one way to reduce project noise, if you don’t see noticeable improvements, take a good look at the individuals creating the noise.  Is the noise a by-product of anxiety as you near a milestone or is the noise created by a disgruntled team member?

5. Think Like Your Parents Did! 

When I started managing projects, I believed that project management was simply about chasing details and working the task list. However, when you step back and assess the amount of time spent on the project, a significant portion is spent simply managing people.

Over the years, I’ve found many parallels between my project management skills and parenting skills. A parent creates guidelines for the family, defines the goals, provides direction and gets to watch the kids grow.  Along their journeys, kids will need an occasional course correction. But, if you set them up for success from the beginning, the results are usually positive, which is very similar to managing projects.  

So I need to be parenting instead of project managing?

Not literally, but in my opinion, highly effective project managers are also great parents.  Parents have a lot of experience finding the balance between chasing details and managing people.


All in all, there are many factors that have contributed to making IT projects run at a faster pace.   For example, technology improvements that keep us constantly connected to work via our smart phones result in doing more than we used to. This raises the bar on productivity.  Technology is also making stuff run faster which increases our expectation that things simply need to go faster.  Remember how long it used to take to send company communications via an inner office memo? How long did it take to run the monthly financial reports that we now generate in minutes? As a result, we have less tolerance for things that appear to take too long. This has become the new norm, resulting in projects that run at the pace of a three minute mile.

Of course, the recent recession has also taught business how to do more with fewer employees. Individuals who were lucky to remain employed accepted the fact that they had to pick up the slack or they might be out of a job.    One thing is clear; the current pace of IT projects is running at a faster clip than what I remember from the eighties. So, if this is the new status quo, we all need to learn how to get in shape and keep up.  This means   creating alignment with the individuals involved, becoming more transparent, co-managing the effort with a partner and reducing or eliminating as much noise as possible. 

Don’t forget to leave your comments below

Steve Pieczko has more than thirteen years experience managing custom software development and implementing packaged products. With a career largely dedicated to the advancement of best practices that leverage the PM’s ability to predictably deliver business value, he has expertise in Financial Services, Telecommunications, Education, Healthcare, Transportation and Insurance. Today, Steve works with Geneca’s enterprise clients to help them achieve business/IT alignment, predictability and clarity.  Steve has an MS in CS from DePaul University. Contact Steve at [email protected].