Back 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 '80s, 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 shaved 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. In addition, 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 are 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.

Conclusion
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. 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 3-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 '80s. 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.