Challenges Managing in the Knowledge Economy? The Answer is Beneath You

As children, many of us grew up with a vision of the manager as “the boss” – a key source of authority in the business who knew the answers, told others what to do and led with a firm hand.  As adults, many of us move into management and try to live that childhood vision – with disastrous consequences.  Why hasn’t the “boss as manager” model work for us today? What’s changed?  Surprisingly, the answer is beneath you.

To understand what this means, consider, first, the era when management as profession came into vogue – the industrial age.  The emphasis had shifted away from the craftsman-apprentice model before mass production, where individuals passed on knowledge one-on-one.  Instead, the secret to success in the industrial age was mass production, which required the standardization of business processes and simplification of tasks so that unskilled workers could more easily complete the work.

A manager’s primary responsibilities were to coordinate the efforts of large groups of people, so a highly regimented top-down management style fit best. The 24-hour day was broken down in to two or three shifts, people were assigned to shifts and they generally completed their assigned work. During this age, a manager’s biggest challenges were employees who didn’t show up on time, who left early or who didn’t complete their fair share of work.  A firm hand was required to prevent abuse and keep productivity up; the “manager as boss” excelled in this world and this management approach flourished.

On to the knowledge age, where knowledge is the key tool used to create products as well as the product itself.   For the first time, many products — semi-conductors, computer hardware, software, even modern phones — rely heavily on knowledge as the key inputs to their creation.  In the knowledge economy, the highest single cost in creating the product is the labor of experts – not manufacturing labor or raw materials.  In turn, making the most of the knowledge of these experts is the key to success – not necessarily making the most of their time.

With the shift from industrial economy to the knowledge economy, the storehouse of knowledge and authority are no longer in the same hands.  In the industrial age, the boss knew best; in the knowledge age, you, as a manager, still have the authority, but the knowledge is beneath you, in the hands of the experts.  To adjust for this, a change in management style is needed.

Based on my conversations with respected managers in the age of knowledge and my own experience, here’s how to succeed as a manager in the knowledge economy:

  1. Ask the experts. This sounds simple and straightforward, but it’s rarely followed.  Because many of us are former experts who moved in to management, we consider ourselves experts still.  Yet, how long does it take before our expertise becomes out-dated when we don’t use it?  As little as six months? As much as a couple of years?  Consider this: If your subordinate knows all of the features of the latest version of your software, but you know all the features of the last one, whose knowledge is more valuable?
  2. Facilitate – don’t order. As managers, we all know that the experts around us are extremely bright – in many cases brighter than we are.  How condescending it must seem, then, when we managers order our team members to execute our instructions.  Instead, help them to identify the problems together, then assist in developing a methodical approach for solving it.  In the process, it will become clear which team members should tackle each step in solving the problem.  No orders necessary.
  3. Coordinate – don’t control. As former experts, we’re acutely aware of the challenge of being “stuck in the weeds” – that desire to keep your head down and focused on solving the problem in front of you.  As much as that tendency toward isolation grips our fellow experts, we should coordinate their efforts and encourage them to work together as a team.  Coordinating the team means bringing them together, discussing key challenges and asking one expert to help another to achieve breakthroughs when addressing a challenging problem.
  4. Serve as a knowledge bridge. In many cases, the specialized knowledge of one expert on your team is very different from the specialized knowledge of another.  For example, one person may specialize in database design, while another specialized in user interface (screen) development.  Because of this, they are often working on very different tasks, even though one person’s knowledge may be needed to solve another person’s problems. As the manager of this team, we know what each team member is tackling and we should know whether they have solved past problems.  It’s our job to connect the dots across the work of our teams, to point out patterns in problems that we see, and to bring together the experts to share their relevant knowledge, solving each other’s problems more quickly and efficiently.
  5. Set challenging (but realistic) goals. Knowledge experts like challenges, so work with them to set short term and long term goals that are SMART – Specific, Measurable, Attainable, Relevant and Time-specific.  As part of the process, be certain to set goals to be a little more challenging than the person believes is possible – but not so difficult that the person ignores the goal because he or she thinks it’s impossible.
  6. Value the individual. In the industrial age, the loss of an individual team member was disappointing, but it wasn’t likely to cripple your business, your division or your projects.  In the knowledge age, there are people who are so essential that their departure could force the business to crumble.  While I would argue that it has always been important to treat people well, in the knowledge age, it’s even more important to treat each individual with respect and consideration.

In many respects, the knowledge economy has made managing more challenging.  In many management positions, “people” skills are more important than analytical abilities.  Even more challenging, your position as manager often makes you more expendable than your subordinates.  Combined, it’s critical to your success as a manager to look beneath you for the knowledge and expertise for you and your organization succeed.

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 https://cedarpointconsulting.comm.


Experience and the Turnaround

While at a business conference earlier this year, a fellow I had just met mentioned to me in an offhand way that they (his business unit) had just hired a young guy out of a prestigious business school program to “fix” their business, which has been on the decline for the past three years. They hired this guy as a permanent employee, and the CEO had great hopes that he would bring the company back into the black by the end of this year, using the latest business strategies. He reports directly to the CEO, not the head of the business unit.

After all, he did have a perfect GPA at the B-School he attended.

I hope that works out for them, but I did give him my business card. “Just in the instance that the task turns out to be a little bigger than you thought”, I said.

Now for some business-style preaching:

When managing a business turnaround, there is a great deal of reliance on data, on forecasts, on costs, on efficiency, on quality, etc. And many of the things you do to fix the company are the things taught in most business schools and/or internal management training programs at large corporations.

So, any young over-achiever right out of business school with the most up-to-date academic knowledge can probably fix what’s ailing your business and get it turned around pretty quick, right?

I’m waiting…

Yeah, that’s what I thought. Good answer.

Not many business owners or business CEOs are going to trust a turnaround to someone who doesn’t have a fair amount of battle experience. And believe me, it will be a battle, and there will be casualties.

Whether that trust from the person managing the business is because of their own business experience, or because of their intuitive belief that an experienced, steady hand is what’s needed in this type of dire situation, that trust is not misplaced.

Experience is what enables you to manage a crisis, and keep a crisis from degenerating into chaos.

Experience is what lets you walk into a process shop and know immediately that there are problems there.

Experience gives you the ability to monitor several dozen calls in a call center and quickly figure out why average talk time has gone through the roof.

Experience allows you to sense the submerged hostility between the head of operations and the head of sales and marketing, and realize they’re been sabotaging each other for years, and that mutual sabotage has now brought down the company. And it also allows you to realize that the COO won’t do anything to stop it because he is extremely competent but completely non-confrontational.

Experience lets you ascertain almost immediately that the guy in charge of IT is much more interested in building “the perfect beast” in terms of the company server, the website platform, etc. than doing what is best for the company, even if that means he doesn’t get those new Sun server boxes until next year, or the website update gets put off until after the busy season is over. And the company president doesn’t know enough about technology to challenge him on it.

Experience is what gives you the ability to figure out pretty quickly that the CFO stopped really caring about her job sometime ago, and for whatever reason, is now just basically going through the motions, and that there may be some gains available to the business by using cash flow more effectively, or more diligent oversight of expenditures – if someone would just do it.

It’s not that I want to portray experience as some black magic or some intangible “art” that is both mystical and inexplicable, but I also don’t want to discount its value when time is crucial and the health of the business is slowly ebbing away. If nothing else, many times it will prevent you from running down blind alleys at full speed for a couple of months, if only for the simple reason that you’ve already run down that blind alley before. It helps, it really does, and as long as you don’t get stuck in the “well, this is the way we’ve always done it before, and so this is the only way that will work” trap, experience is a big plus in turnaround efforts.

So, that concludes today’s sermon, congregants. I’m going to step down from my pulpit now, and I hope to shake your hand and wish you well as you exit. May Providence be with you.

Brendan Moore is a Principal Consultant with Cedar Point Consulting, a management consulting practice based in the Washington, DC area, where he advises businesses in rebirth and rejuvenation. 


Are You Planning to Crash?

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, 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 applying Lean and Agile to develop new products and services as well as improve organizational performance. Cedar Point Consulting can be found at https://cedarpointconsulting.com.


Intuitive to Whom? In Web Design, it Matters

During a recent Management Information Systems course I taught for the University of Phoenix, I posed the discussion question to students, “What do you think are the most important qualities that determine a well-designed user interface?” While responses were very good, nearly all of my students used the term “intuitive” in their response without providing a more detailed description, as though the term has some universal, unambiguous meaning to user interface (user experience) designers and web users alike.

I responded by asking, “Intuitive to whom?…Would a college-educated individual and a new-born infant both look at the same user interface and agree it is intuitive? Or, would the infant prefer a nipple providing warm milk to embedded-flash videos of news stories?”

Far from obvious, an “intuitive” user interface is extremely hard to define because “intuitive” means many different things to many different people. In this article, I challenge the assumption that “intuitive” is obvious and suggest how we can determine what intuitive “is”.

Nature and Nurture

Our exploration of intuitive user interfaces and user experience starts with “nature” and “nurture”, much like the “Nature versus Nurture” debate that occurs when explaining the talents and intelligence of human beings. For those of us who haven’t opened a genetics book in a few decades, if ever, “Nature” assumes that we have certain talents at birth, while “Nurture” proposes that we gain talents and abilities over time.

Certainly, “Nature” plays a role in an intuitive user interface. According to research by Anya Hurlbert and Yazhu Ling (http://ts-si.org/neuroscience/2464-sex-differences-and-favorite-color-preference), there’s a great deal of evidence that we are born with color preferences and that color preferences naturally vary by gender. In addition, warning colors like red or yellow, such as red on stop signs and yellow on caution signs, are likely a matter of science and genetics rather than learned after we’re born. So, an “intuitive” interface is partly determined by our genes.

“Nurture” also plays a big role in determining our preferences in a user interface. For example, link-underlining on web pages and word density preferences are highly dependent upon your cultural background, according to Piero Fraternali and Massimo Tisi in their research paper, “Identifying Cultural Markers for Web Application Design Targeted to a Multi-Cultural Audience.” While research in personality and user interfaces is still in its infancy, there’s a strong indication that CEO’s have different color preferences from other individuals, as Del Jones describes in this USA Today article.

But, what about navigation techniques, like tabs and drop-down menus? In a recent conversation with Haiying Manning, a user experience designer with the College Board, I was told that “tabs are dead.” This crushed me, quite frankly, because I still like tabs to effectively group information and have a great deal of respect for Haiying’s skills and experience. As a Gen-Xer who spent much of his teen years sorting and organizing paper files on summer jobs, I’m also very comfortable with tabs in web interfaces, as are my baby-boomer friends. My Net-Gen (Millenial) friends seem to prefer a screen the size of a matchbox and a keyboard with keys the size of ladybugs, which I have trouble reading.  (Nevertheless, Haiying is right).

In the end, because of “Nature” and “Nurture”, the quest for an “intuitive” user interface is far more difficult than selection of a color scheme and navigation techniques everyone will like. What appeals to one gender, culture or generation is unlikely to appeal to others, so we need to dig further.

It’s all about the Audience

In looking back on successful projects past, the best user interface designers I’ve worked with have learned a great deal about their audience – not just through focus groups and JAD sessions, but through psychometric profiling and market research. This idea of segmenting audiences and appealing to each audience separately is far from new. Olga De Troyer called it “audience-driven web design” back in 2002, but the concept is still quite relevant today.

Once they better understood their target customers, these UI designers tailored the user interface to create a user experience that was most appealing to their user community. In some cases, they provide segment-targeted user interfaces – one for casual browsers and one for heavy users, for example. In other cases, they made personalization of the user interface easier, so that heavy users could tailor the interface based on their own preferences.

They also mapped out the common uses (use cases or user stories) for their web sites and gave highest priority to the most used (customer support) or most valuable (buying/shopping) uses, ensuring that they maximized value for their business and the customer. More importantly, the user interface designers didn’t rely upon the “the logo always goes at the top left” mind-set that drives most web site designs today.

Think about the Masai

In hopes of better defining what “intuitive” is, I spoke with Anna Martin, a Principal at August Interactive and an aficionado of web experience and web design. Evidently, “intuitive” is also a hot topic with Anna, because she lunged at the topic, responding:

Would you reach for a doorknob placed near the floorboard; or expect the red tube on the table to contain applesauce? Didn’t think so. But what’s intuitive depends largely on what you’re used to.  Seriously, talk to a Masai nomad about a doorknob – or ketchup for that matter – and see what you get. And good luck explaining applesauce. (Cinnamon anyone?). Clearly intuition is dependent on what comes NATURALLY to a user – no matter what the user is using.

So why would the web be any different? It’s not. Virtual though it may be, it’s still an environment that a PERSON needs to feel comfortable in in order to enjoy. Bottom line is this…if you wouldn’t invite your 6 year old niece or your 80 year old grandmother to a rage (did I just date myself?) then don’t expect that every website will appeal to every user.

Know your audience, understand what makes them comfortable; and most importantly try to define what ‘intuitive’ means specifically in regards to sorting, finding, moving, viewing, reading and generally experiencing anything in their generation.”

So, audience-driven web design has firmly embedded itself into the minds of great designers, who must constantly challenge the conventions to create truly creative interactive experiences on the web. Consequently, as the field of user design transitions into a world of user experience, it’s going to require second-guessing of many of the design conventions that are present on the web today. This not only means pushing the envelope with innovative design, it also means we need to have a good handle on what “intuitive” really is.

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 https://cedarpointconsulting.com.

Baby Bottles and Web Design


Departing Waterfall – Next Stop Agile

It’s been more than a year since I penned, “Before Making the Leap to Agile”, an article intended to guide everyone from C-level executives to IT project managers on the adoption of Agile. The goal was to offer up some of the lessons I learned through actual implementations, so that readers could avoid of some of the pitfalls associated with Agile adoption.  While a few saw it as an assault on Agile, many understood that my goal was to assist Agile adopters and thanked me for writing it.

Five-thousand-plus page views later on the last article, and I’ve finally cleared my plate enough to address an equally important topic: why people, and organizations, are making the shift to Agile from the more typical Waterfall. After all, Agile is a revolutionary approach to software development and it continues to grow in popularity, so I think it’s important for those who do not yet use Agile to understand why others have embraced it.

Why are people abandoning Waterfall and moving to Agile?

1. Agile is Adaptive. For the project team, as well as the business, Agile enables you to make quick changes in direction so that your software product and your business can respond to a rapidly changing business environment.

How? Agile teams use two-to-four week iterations, often called sprints, in which to develop and then release a working product.  At the end of each sprint, the team uses retrospectives to look back on the work completed and see how productivity can be improved; the team also works with the customer to determine which work should be accomplished during the next sprint.  One technique enables continuous improvement, the other enables the business to re-prioritize work based on changes in the business climate.  Together, they make Agile highly adaptive when compared to a Waterfall approach that effectively locks the team in to both a process and business strategy for a number of months.

2. WYSIWYG (What You See Is What You Get) Development. Many of us are familiar with this wonderful cartoon that shows how projects really work — at least in a Waterfall world. Notice how there’s an enormous disconnect between the first image, “what the customer asked for”, and the last, “what the customer really needed”.

Arguably, this happens because those of us in software development listen dutifully to what our customer says, document their words in the form of requirements, and then go off and build it, assuming all along that our customer knows not only what they want – but what their end customers want.  In reality, many of us have a rough idea of what we want and often less of an idea of what our customers want, particularly with software products that serve the masses (sure, focus groups and usability testing make a big difference, but still fall short in many instances).

Agile takes an entirely different approach to requirements gathering. Product features are identified for development and then the team works together with the business customer to build the features cooperatively. In many cases, user stories are written, screen mockups are drawn and simple business rules are written, but nothing too sophisticated. Instead, the Agile team relies upon heavy interaction with the customer or product owner to elicit requirements on-the-fly.

For example, not sure what the business customer wanted on a particular screen? Show them what you’ve got and see if it fits their expectations. Even if it is what they asked for, see if it’s going to serve their customer’s needs as they intended, or if it needs some refinement. Either way, if they want a change, change it. Using this nimble approach, there is little risk of misinterpretation of requirements and even less risk that the finished product misses the mark.

3. Shorter Time-to-Market. Let’s be honest here – who among us hasn’t reported to a C-level who has a great idea and wants something on the market – yesterday. (Heck, I’ve been guilty of this myself). Using a Waterfall approach, delivering anything to the marketplace takes months and sometimes years. But, by taking an Agile approach, the bare-bones features of a new product can be delivered in weeks, then, further enhanced to provide a truly robust solution. Again, the secret to shorter time-to-market lies in the use of iterations (sprints), with the end of each sprint another opportunity to deliver more features to the customer. Agile has this – Waterfall doesn’t.

4. Greater Employee Satisfaction. One of the oft-cited byproducts of Agile development is greater employee satisfaction – both by the project team and the line-of-business responsible for delivering the product. According to Steve Greene and Chris Fry, Salesforce.com reported an 89% employee satisfaction rating after adopting Agile when compared to only 40% before adoption.

In a similar vein, research by Grigori Melnick and Frank Maurer from the University of Calgary showed 82% of employees at Agile-adopting businesses were satisfied or very satisfied with their jobs, while only 41.2% were satisfied or very satisfied in non-Agile shops (2006, Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams).

5. Higher Quality. By most accounts, adopting Agile reduces defects and results in higher product quality. While personally I have seen Agile projects head in the wrong direction and suffer from higher defect rates initially, many sources have noted significantly higher quality on Agile projects. According to a 2008 survey by Version One, 68% of respondents to a survey on Agile adoption and corresponding results reported improved product quality as one of the benefits (3rd Annual Survey on the State of Agile Development). Similarly, David Rico, et. al report on average a 75% improvement in quality by adopting Agile (The Business Value of Agile Software Methods, 2009, J Ross Publishing).

6. Higher ROI. If there’s one single reason for the corner office to be sold on Agile, it has to be higher ROI. Because Agile reduces project overhead, delivers beneficial work more quickly and produces higher quality products, Agile also delivers a higher ROI to the businesses who adopt it. According to research that compiled data from multiple different sources, including Microsoft, Version One and the University of Maryland, Agile projects average an 1788% ROI when compared with Waterfall projects at 173% (The Business Value of Agile Software Methods, 2009, J Ross Publishing). While these numbers appear to be skewed toward the low side for Waterfall because the comparison only included CMMI-adopting organizations, that hardly makes up for a 10-fold difference between the two.

With all of this evidence residing squarely in the corner “for” Agile adoption, it’s sometimes hard to understand why Waterfall is still practiced. But the truth is, adopting Agile takes a paradigm shift in thinking that is not easy for individuals, much less organizations, to make. It also takes experience not only in practicing Agile, but also in managing organizational change, two qualities critical in Agile consultants.

This is why the Cedar Point Consulting team tailors its Agile implementations to each organization, choosing the tools and techniques that best match your industry and needs so that you avoid many of the pitfalls and have a successful adoption. It’s also why I have personally put so much time and effort into making Agile even more robust, not only by exploring Agile at Scale, but also by off-setting some of Agile’s weaknesses with common-sense approaches that nearly every business can implement.

So, go ahead, make the leap to Agile. Just be certain you’re taking the right approach to Agile adoption for your organization before you begin.

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 https://cedarpointconsulting.com.

 

Waterfall Model diagram