Are You Planning to Crash?

Leave a comment

Nearly every experienced project manager has been through it. You inherit a project with a difficult or near-impossible schedule and the order comes down to deliver on time.  When you mention how far the project is behind, you’re simply told to “crash the schedule”, or “make it happen.”

As a long time project manager who now advises others on how best to manage projects and project portfolios, the term “schedule crashing” still makes me bristle. I picture a train wreck, not a well-designed product or service that’s delivered on time, and for good reason. While schedule crashing sounds so easy in theory, in practice schedule crashing is a very risky undertaking that requires some serious evaluation to determine whether crashing will actually help or hurt.

In this article, I’ll explain the underlying premise behind schedule crashing and describe some of the typical risks involved in a schedule crashing effort.  Then, I’ll provide seven questions that can help you assess whether schedule crashing will really help your project.  Combined, the schedule crashing assessment and the risks can be brought to executive management when you advise them about how best to proceed with your project.

Schedule Crashing Defined

As defined by BusinessDictionary.com, schedule crashing is “Reducing the completion time of a project by sharply increasing manpower and/or other expenses,” while the Quality Council of Indiana‘s Certified Six Sigma Black Belt Primer defines it as “…to apply more resources to complete an activity in a shorter time.” (p.V-46). The Project Management Body of Knowledge (PMBOK), fourth edition describes schedule crashing as a type of schedule compression, including overtime and paying for expedited delivery of goods or services as schedule crashing techniques (PMBOK, p. 156), though I generally think of overtime as another type of schedule compression – not crashing.

From a scheduling perspective, schedule crashing assumes that a straight mathematical formula exists between the number of laborers, the number of hours required to complete the task, and the calendar time required to complete the task. Said simply, if a 40-hour task takes one person five days to complete (40 hours/one person * 8 hours/day=5 days), then according to schedule crashing, assigning five resources would take one day (40 hours/5 people*8 hours/day=1day).

The Risks of Crashing

Frederick Brooks had much to say about the problems with schedule crashing in, “The Mythical Man-Month“. In this ground-breaking work about software engineering, Brooks explains that there are many factors that might make schedule crashing impractical, including the dependency of many work activities on their preceding activities and the increased cost of communication. This phenomena is now referred to as Brook’s Law–adding resources to a late project actually slows the project down. I personally saw Brook’s Law in action on a large program led by a prestigious consulting firm where the client requested that extra resources be added in the final two months of the program; because the current resources were forced to train new staff instead of complete work, the program delivered in four more months instead of two.

Additional risks of crashing include increased project cost if they crashing attempt fails, delayed delivery if the crash adversely impacts team performance, additional conflict as new team members are folded into the current team to share responsibility, risks to product quality from uneven or poorly coordinated work, and safety risks from the addition of inexperienced resources.

In short, schedule crashing at its most extreme can be fraught with risks. Managers at all levels should be very cautious before recommending or pursuing a crashing strategy.

Making the Call to Crash

So, how can a project manager decide if crashing will help? Here are seven questions I ask myself when deciding if crashing is likely to succeed:

  1. Is the task (or group of tasks) in the critical path? Tasks in the critical path are affecting the overall duration and the delivery date of your project, while tasks outside of the critical path are not affecting your delivery date. Unless the task your considering crashing is in the critical path or will become a critical task activity if it substantially slips, crashing the activity is a waste of resources.
  2. Is the task (or group of tasks) long? If the task is short and does not repeat over the course of the project, then it’s unlikely you’ll gain any benefit from crashing the activity. A long task or task group, however, is far more likely to benefit from the addition of a new resource, as can tasks that require similar skills.
  3. Are appropriate resources available? Crashing is rarely useful when qualified resources are not available. Is there a qualified person on the bench who can be added to the project team to perform the work? If not, can someone be brought in quickly who has the needed skills? Recruiting skilled resources is a costly and time-consuming activity, so by the time the resource(s) are added to your team, the task may be complete and your recruiting efforts wasted.
  4. Is ramp-up time short? Some types of projects require a great deal of project-specific or industry-specific knowledge and it takes time to transfer that knowledge from the project team to the new team members. If the ramp-up time is too long, then it may not make sense to crash the schedule.
  5. Is the project far from completion? Often, people consider crashing when they’re near the end of a project and its become clear that the team will not meet it’s delivery date. Yet, this may be the worst time to crash the schedule. Frederick Brooks told the story about his schedule crashing attempt in “The Mythical Man-Month” where he added resources to one of his projects at the tail end, which further delayed delivery. In most cases, schedule crashing is only a viable option when a project is less than half complete.
  6. Is the work modular? On many projects, the work being delivered is modular in nature. For example, in automotive engineering, it’s possible for one part of the team to design the wiring for a new vehicle model while another part of the team designs the audio system that relies upon electricity, as long as points of integration and dependencies are defined early. Through fast-tracking, or completing these tasks in parallel, it becomes beneficial to also add resources, crashing the schedule.
  7. Will another pair of hands really help? All of us have heard that “too many cooks can spoil the broth,” but this also applies to engineering, software development and construction. Consider where the new resources would sit, how would they integrate with the current team, would their introduction cause an unnatural sharing of roles?

If you’ve answered these questions and responded “yes” to at least five of the seven questions, then you have a reasonably good project-crashing opportunity; a “yes” to three or four is of marginal benefit, while a “yes” to only one or two is almost certain to end for the worse.

Alternatives to the Crash

Fortunately, there are alternatives to schedule crashing that may be more appropriate than the crash itself.

  1. Increase hours of current resources. For a limited time period and within reason, asking current team members to work overtime can help you reach your delivery date more quickly than schedule crashing. When considering overtime, it’s important to remember the caveats, “a limited time period” and “within reason”. Asking resources to work 50-60 hours a week for six months is unreasonable, as is asking resources to work 70 hours per week for a month for all but the most critical projects.
  2. Increase efficiency of the current team. Though it’s surprisingly rare on projects, examining current work processes and adding new time-saving tools can improve the productivity of a team by 10% to 50% or more if a project is long. I once led a team that increased it’s productivity by roughly 30% simply by re-sequencing work activities and adding a single team member to speed up cycle time at a single step in the process.
  3. Accept the schedule. In some cases, it’s better to offset the downside effects of late delivery rather than attempt to crash the schedule. In some cases, this amounts to using a beta or prototype for training rather than a production-ready product.

A Final Caution About Crashing

Because it’s rarely well understand by anyone other than project managers, schedule crashing is often recommended by co-workers who really don’t understand the implications of the decision.  While they see an opportunity to buy time, they almost never see the inherent risks.

As a result, it’s critical that project managers not only assess the likelihood of success when considering crashing as an option, they also educate their stakeholders, their sponsor and other decision-makers about the risks of a schedule-crashing approach.  Doing anything less perpetuates the myth that crashing is a panacea that cures all that ails a late project, potentially creating much bigger problems for everyone down the road.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.


Toward a More Robust Agile


In a previous article, I put together a list of some of the weaknesses of the Agile software development methodology that I’ve learned from other software experts and on my own as a consultant serving the technology industry.  As expected, some people were upset that I pointed out so many weaknesses in Agile without pointing out its advantages, believing I was being unfair.   It is true that there are many benefits to adopting Agile over other methodologies.  But, I was actually preparing fertile ground for my next article – Toward a More Robust Agile.

As you may remember, my last article identified ten weaknesses with Agile, including:

  1. True Agile is rarely practiced.
  2. Agile requires heavy customer interaction.
  3. Agile thrives with co-located teams, but struggles with distributed teams.
  4. Agile is difficult to scale for large projects and large organizations.
  5. Agile provides weak architectural planning.
  6. Agile has limited project planning, estimating and tracking.
  7. Agile requires more re-work.
  8. Agile makes contractual commitments difficult.
  9. Agile poses challenges to business continuity and limits knowledge transfer.
  10. Agile lacks attention to outside integration.

As I pointed out, these weaknesses should cause some organizations to hesitate before adopting Agile, particularly in large complex environments where most business processes are highly formal and the culture is risk averse.  C-Level IT executives (CIO/CTO), heads of software development, heads of PMO’s and lead project managers should research further before considering the leap to Agile seriously.

Fortunately, Agile is not a static, take-it-or-leave-it methodology, so variations, improvements and customizations are being made and adopted as I write this. One of these improvements, however, is worth an in-depth exploration.

Already understanding some of the weaknesses inherent in Agile, one software development expert began to address them in 2007 – Dean Leffingwell. In “Scaling Software Agility: Best Practices for Large Enterprises,” Leffingwell responded to many of the challenges posed by adopting Agile in large-scale environments, particularly items 2,3, 4, 5, 6 7, 8, 9 and 10 above. In doing so, Leffingwell made Agile both feasible and attractive to large businesses and large-scale software development projects – environments where Agile once struggled.

At the heart of Leffingwell’s approach is believing that Agile is inherently strong, but is not without flaws. In his own experience, he saw that some additional structure and planning were needed to coordinate large-scale efforts, much like I described earlier. Leffingwell’s response too beefing up Agile is five-fold:

  1. Make Architecture Intentional. Rather than treating architecture a byproduct of iterative software development, make architecture planned and deliberate. (Scaling Software Agility, Chapter 16)
  2. Use a Lean approach to requirements. First, define high-level requirements early, then hash out details when they’re absolutely needed, much like just-in-time inventory. (Scaling Software Agility, Chapter 17)
  3. Scale Agile using a team-of-teams, a system-of-systems and release trains. (Systems of Systems and the Agile Release Train: An Agile Whitepaper) . In Leffingwell’s scaleable Agile, the key to coordinating large software projects is to break them up into smaller ones and coordinate them, much like a program. According to Leffingwell, just as a group of interrelated projects are programs, a group of Agile teams can be combined to form a program team with program leadership, called a team-of-teams. Each Agile team focuses on a particular piece (component) of the software, or system, which combined makes up a system-of-systems. To pro-actively coordinate the team-of-teams building the system-of-systems, a release train synchronizes the iterations of each team so that their work meshes together at the end of each iteration, ensuring that the needed software features are delivered on schedule.    Beyond a specific release, epics tie many releases together, allowing for long range planning and architecture.
  4. Accept the distributed geography of software development teams and provide virtual tools to coordinate global efforts. In Leffingwell’s approach, a primary team is placed on-site with the client, while one or more off-site teams share work and coordinate with the on-site team using wiki’s, VoIP/Skype and web conferencing. (slide 87, 2007 presentation)
  5. Recognize that a shift to Agile is a major cultural change for a large organization, requiring stages and a roadmap. Rather than try to make the leap from Waterfall to Enterprise Agile all at once, Leffingwell suggests a five-step adoption path from individual Agile teams to multi-team programs and on to multi-program organizations. (slide 92, 2007 presentation).

Combined, Leffingwell’s Scalable Agile resolves many of the problems that large teams encounter with Agile, at least on paper. For me, I like that Leffingwell borrows from RUP (Rational Unified Process) and Lean manufacturing principles, two topics that I’m both familiar with and respect. I also like that he understands the large organization, the need for heavy coordination throughout, as well as the need for long range strategic, portfolio and architectural planning.

And, as you can see from the diagram below, this re-positions Agile to be more competitive with Waterfall and RUP for larger and more complex projects.

Agile methodology positioning

Agile methodology positioning

Not accepting theory alone as a solution, however, I talked with a friend who is implementing Leffingwell’s version of Agile-at-Scale in his organization to see how the effort is going, where the organization is encountering issues and whether he thinks Agile-at-Scale will work for them.  Though I can not reveal confidential information, he was able to provide anecdotal support for Agile-at-Scale, which is quite promising.

However, it would be great to hear from Agile experts who are implementing Leffingwell’s Agile-at-Scale or making similar changes to Agile to make it more robust.

Without providing confidential information, please tell us…

  1. How large is your organization (people, revenue)?
  2. How long has your organization been pursuing Agile?
  3. How long  have you been working with Agile-at-Scale?  How far are you through Leffingwell’s five step adoption path?
  4. Are you happy with the results you’re seeing?
  5. What are some of the biggest issues you’ve encountered to-date?
  6. Given what you’ve seen, do you think you’re Agile-at-Scale effort will succeed?

While it’s a little early to tell, Agile is clearly evolving to become more attractive to larger, more structured organizations and maturing to provide a viable alternative to Waterfall and even RUP.  When I return to this topic, I will talk about some ways to ease in to Agile, adopting Agile tools and techniques in your environment without completely abandoning a Waterfall approach.

Interested in other articles like this one?  Read “Departing Waterfall-Next Stop Agile“.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

Before You Make the Leap to Agile – Ten Weaknesses of the Agile Methodology


It’s been nearly a decade since Martin Fowler, Ken Schwaber and fifteen other experts in the software industry wrote the Agile Manifesto outlining an approach to software development radically different from the Waterfall model that dominated the 1980’s and 1990’s. Since that eventful time in 2001, Agile software development methodologies, including the use of Scrum, XP (Extreme Programming) and Crystal, are all the rage throughout business and government, attracting praise like a miracle drug. As of early 2010, Agile is till one of the more popular buzzwords in software development.

If you’re in the captain’s chair as a C-Level IT executive (CIO/CTO), the head of software development, the head of your Project Management Office (PMO) for your business, or the lead project manager in a small organization, you may be considering the leap to Agile seriously. The good news is that Agile is working well for many businesses and on many software development projects.

The bad news is that Agile is not the magic bullet many are claiming it to be. As many successes as there are in Agile development, there are also many failures in both the adoption and use of Agile in software development. (Here’s a list here of some cautionary tales, provided to support my statements, not to complete turn you away from Agile: The Great Pyramid of Agile, Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong, Agile: Anatomy of a Failed Project, A Scrum Project That Failed.)

The fact is that seasoned business and IT leaders, particularly those at larger businesses, should take a closer look before plunging in to the Agile world with reckless abandon. Agile has a number of weaknesses that many disciples of Agile fail to acknowledge. After all, they’re in the business of developing with and helping you to adopt Agile, so they’re not likely to tell you about its problems and limitations.

Together with my friends and fellow associates at Cedar Point Consulting, we’ve come up with this list of Agile weaknesses, which apply to Agile as it is most commonly implemented:

  1. True Agile is rarely practiced. Long-time practitioners will tell you, “It’s Agile – not agile”. Without a doubt, the biggest single problem I have encountered in Agile-practicing shops in the past decade has been that too few people truly understand and practice Agile. In many cases, software developers, development managers and consultants alike mistake Agile for its lowercase sibling, agile, and assume that Agile is all about flexibility and absence of process.This is far from the truth. Agile has formal rules and structure, though they are quite a bit different from those of other development approaches. Agile is iterative, it is adaptive and it is supported by some outstanding tools and techniques, like burn-down charts, product backlogs, user stories and stand-ups. Most important, Agile is not anarchy. It does not mean that everyone does whatever they want and there’s no sense of organization, despite the fact that you may feel this is the case.
  2. Heavy customer interaction is essential. Reflected in principles four and five of the Agile Manifesto, heavy customer interaction is one of the biggest benefits of Agile, but it also becomes a weakness in some environments. Consider, for example, situations where the customers or users of the software being developed do not have the time available to meet with members of the software development team on a frequent basis? What if the key customer is the CEO, who often has more important matters to address? What if you’re not permitted to talk with the users?One important thing to know about Agile development teams is that they are high maintenance – they work quickly, but they also require much more time and attention from the business side to be able to work quickly. If that time cannot or will not be spared for their benefit, using an Agile approach will bring little gain over a Waterfall approach.

Click here to read the rest of this article on Cedar Point Consulting’s web site.


Interested in other articles like this one?  Read “Departing Waterfall-Next Stop Agile” and “Toward a More Robust Agile“.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in process improvement, project management methodologies and technology strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

Watch that Basket-Seven Ways to Identify Troubled Projects

Leave a comment

Though the traditional advice is “don’t put all of your eggs in one basket,” the celebrated author Mark Twain is famous for saying, “…put all of your eggs in one basket and — WATCH THAT BASKET.”

Whether you’re a an entrepreneur leading a small business , a C-Level executive (CEO/CFO/CIO/CTO) at a mid-sized business, the head of the Project Management Office (PMO), or a business manager watching out for your department, you are often stuck in the position of having to “watch that basket” with your most critical projects.

Even worse, many times you’re never truly sure if one of your key projects is in trouble until it’s too late.

Fortunately, there are some signs that can help you identify a troubled project early, so that you can intervene and put it back on track. I polled our project recovery services specialists at Cedar Point Consulting, and we thought of seven effective ways to identify a troubled project:

  1. Perpetual Green Lights, Little Activity. Many of us are familiar with the approach of labeling projects green when they are on schedule and budget; yellow when the project is falling behind; and red when the project is far behind and/or over-budget. Perhaps your key project has been reporting green for the last three months, but oddly there’s been very little activity related to the project. This is probably a good signal that the project is actually in trouble.
  2. Lot’s of TBD’s. Effective risk and issue management are critical to the success of most projects, yet they are often ignored. If your key project is well past the early stages, but is reporting back a lot of TBD’s (to be determined) in the “resolution” column for risks and issues, then it’s probably a troubled project, even when the schedule doesn’t show it.
  3. Avoiders. The leader in charge of your key project may be a formal project manager or a manager of a business line, but regardless of who they are, you are getting the unsettling feeling that they are avoiding you. Perhaps they are missing at meetings, they’re head the other way down the hall when they see you, they’re not returning phone calls, or they’re not providing status reports. Unless you have a problem bathing, the project leader is likely avoiding you because the project is in trouble.
  4. Troubling Trends. Experienced project managers are familiar in using techniques like earned value management (EVM) to identify project progress by comparing actual to planned results for work completed, costs incurred and time spent. Though you may not be using EVM on your projects, you can watch for dramatic increases or drops in spending, dramatic changes to the work being delivered or sudden changes to schedule with no new schedule dates. In many cases, your key project is in a free-fall.
  5. Non-Progress Reports. You’re wise, so you have asked your project manager to provide status reports on a weekly basis. However, they’re more like “Non-Progress” reports than progress reports because no progress has been made. In particular, if you have received two weekly status reports where no progress has been made, you’re well on your way to having a troubled project on your hands, if you don’t already.
  6. Inability to Show Tangible Results. Well in to your project timeline and knowing that interim reviews are a good idea, you ask for a review or demonstration of work completed thus far. However, your review meeting is repeatedly delayed and rescheduled, sometimes by a few days and sometimes by weeks. Even worse, you’ve tried a quick visit by the desk of the project leader and it resulted in the person shoving documents in their desk instead of sitting with you to review tangible results. If so, this is likely a troubled project.
  7. Spidey Senses Tingling. Like Peter Parker in the Spiderman comic book series, you know which projects are highest risk and every time the subject of your key project comes up, it sets your spidey senses tingling, though you’re not certain why. While I’m a big believer in science over emotion, there is surely something very scientific that you’re reading so trust your instincts. Your likely to find something amazingly like trouble in your key project.

Of course, identifying a troubled project is one thing, but recovering that project is a completely different challenge. I provided some tips to recover troubled projects in a previous article that may be of help.

However, particularly if you don’t have experience recovering troubled projects and the stakes are high, it might be time to consider getting some help.  Our firm provides project recovery services and we’re proud of our success rate, but other competent firms do, as well.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy. Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

VoIP, Virtual Teams and the International Pause

Leave a comment

The Internet is making us all a little more rude these days and there’s a good chance we don’t even know it.  This has nothing to do with texting while driving or blogging about gossip – it’s much more insidious. It is related to using Skype, Vonage and other types of Voice-over-IP (VoIP) on international calls, so if you’re using VoIP phones or you lead virtual teams, there’s a good chance you’re at risk.

As you probably know, the Internet and major telecommunications systems use fiber optic cables, wireless networks and satellite systems that travel near the speed of light, yet they are still limited by distance, the number of hops and the speed of the equipment to determine how long it takes for information to reach your computer. Loosely speaking, this is called latency, and its higher over longer distances and lower over shorter distances.

Because of latency, on a good day, it takes about 1/5 of a second for a single piece of information containing your voice, called a packet, to travel from New York City to Los Angeles and 1/3 of a second from the U.S. to India (Verizon SLAs)– theoretically not too bad if you’re looking to hold a conversation. Unfortunately, the problem is that you’re not just sending one voice packet when you talk, you’re sending thousands. Those thousands of little bitty packets take multiple directions to reach their destination, once they reach the destination they’re reassembled into your voice, and only then are they heard by the person on the other end. This all adds up to between a ¾ and 1½ second delay between when you speak and when your voice is heard. Of course, it can be quite a bit worse when there are bottlenecks on the Internet, so a 2 or 3 second delay is not out of the question, as this article about latency posted at Sat Magazine concludes.

Latency alone is just a technological problem, and not a very big one – until you add human beings into the mix.  A 1½ second delay might not seem like very long, but there is a magic threshold at around 1 second that dramatically changes the shape of human conversations, according to Maryam Alavi, who conducted pioneering research into technology-aided learning in the 1990’s. Consider that, in a typical conversation between two people in the same room, interrupting that person mid-sentence is considered to be rude, while a 1 second pause is usually a signal to the other person that you’re opening up the opportunity for them to respond to your last statement. Similarly, if you have been speaking and the other person does NOT respond within a few seconds, it becomes a pregnant pause.

Conclusion:  Latency + human conversation = unintentionally rude behavior.

For better understanding, here are a some examples of how VoIP conversations, particularly conference calls, have been misread:

  • During a conference call, no one speaks for a full second, so I started to talk. Unfortunately, three other people on the call heard a 1-second pause and started to speak, as well. Suddenly, four people are speaking at once – which is often interpreted as disrespectful.
  • During another conference call, I don’t hear anyone speak for nearly two seconds, so I start to talk. However, the person speaking didn’t actually pause — their voice packets were delayed — so they haven’t finished speaking. When I chimed in, their speech suddenly continued, and I appeared to be interrupting them.
  • During a VoIP call, a person in the room with me spoke for around thirty seconds and then waited for a response. A second, two seconds and then three seconds passed, yet nothing was heard on the other end. Were they offended by what you said? Was it so earth-shattering that they couldn’t think of a response? Did the line suddenly drop?
  • During a conference call, four people in a remote location are in a single room and are using a half-duplex speaker phone (described by HelloDirect). They speak and speak within their conference room, never pausing to allow communication to flow the other direction.  On your side, people are practically yelling in to the phone, but nothing they say can be heard. As a result, the people onyour end think they are being ignored by the other group.

The bad news about all of these situations is that centuries, if not millennia, of human communication have wired us to interpret interruptions and long pauses in speech as rude, but the technology is in many ways introducing the problem.

The good news is that there is a way we can deal with the problem – the international pause. The international pause means pausing for an extra second or two before speaking on a VoIP call, particularly on international conference calls, in order to avoid interrupting someone else speaking.  In short, it’s a way to counteract the effects of latency that occur on IP telephone calls crossing international boundaries.

Using the international pause is simple:

  1. When you start a meeting that uses VoIP or crosses international boundaries, remind people that there are often lags in communication due to the Internet and that it may be a good idea to wait a little longer before jumping in on a conversation.
  2. As a meeting facilitator, remind people to take more frequent pauses when speaking, so that others will have an opportunity to ask questions or make comments. In addition, consciously ask all participants if they have comments or questions before moving on from one subject to the next.
  3. Take an international pause yourself – before speaking, count an extra second or two, then start to talk.

While we could all wait for technology gurus to overcome the problems of latency with VoIP, there’s a great deal of benefit in IP telephone products like Skype, which dramatically reduce communication costs and enable virtual teams to function effectively while spanning the globe. In order to use this new technology effectively without causing strife among virtual teams, however,  it’s important to take an international pause on your VoIP phone calls.

Donald Patti is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in project management, process improvement, and small business strategy.  Cedar Point Consulting can be found at http://www.cedarpointconsulting.com.

%d bloggers like this: