During the ensuing discourse respondents from around the world posted not less than 18 different answers to this question.

Among the responses were answers such as “having poor stakeholder involvement,” “not enough project planning,” “poorly documented requirements,” “the budget being too small or poorly estimated,” and “the [project] goal is not consistent.” To be sure, many of these 18 answers are highly relevant to the success of a project — and yet, every single answer was wrong. None of the 18 responses identified the single, most common mistake of project managers.

In fact, each answer emphasizes the root of the problem: Too many project managers are focused on the day-to-day problems of the project and have lost sight of their overall strategy. They are thinking tactically, putting out fires, rather than strategically — making sure the fires never happen in the first place.

Take, for example, a few of the more common issues raised in this discussion:

1. Poor stakeholder involvement. Let’s assume for a minute that we have a solution to this problem — perhaps, for example, a project manager has correctly identified all the stakeholders, put together a great communication plan to keep the stakeholders informed, and succeeds in building a collaborative environment with the stakeholders “at the table” on a regular basis. If this solves the problem of stakeholder involvement, does it actually save most of the projects that go off the rails?
2. The budget was too small. Again, let’s assume that the right process was used to estimate the project from the start, and that the project manager uses a solid method for measuring performance, cost, and schedule (say, Performance Based Earned Value). Certainly, budget overrun is a common problem, but would this actually solve most project problems?
3. Poorly documented requirements. In my experience, every requirement is poorly documented to start with — so, let’s assume that the right approach is taken to turn poor requirements into great requirements. Quality assurance is involved early, a full-circle approach ties requirements to work product to acceptance, excellent change management is used, and stakeholders provide a final consensus. Will producing great requirements really save more projects than any other strategy?

The list, of course, goes on quite a long ways — and that’s the point. The list is long, and every single item raised is a valid concern for project managers. But with 18 different root causes on the table, could any one of them really make that much difference is the overall landscape?

These are all tactical solutions to specific project problems. So what’s the big picture? What is the one thing that would actually make the biggest difference, that would actually address many, perhaps even most of these 18 different issues?

Let’s take another look at KPMG’s survey of 252 organizations, and their subsequent findings. According to the study, inadequate project management implementation constitutes 32% of project failures, lack of communication constitutes 20%, and unfamiliarity with scope and complexity constitutes 17%. Taken together, 69% of project failures ultimately trace back to poorly implemented project management practices. What this means is simple: Project managers need to step back from the tactical, day-to-day fire fighting, and take a more strategic view. Adopting the right project management strategy will address most of the problems at hand.

How so? Let’s reconsider those first three project issues above.

1. Poor stakeholder involvement. A thorough project plan, adopted out of an appropriate project management methodology that is fit for the purpose, will place the right emphasis on stakeholder involvement. It will also provide the right tactical tools make sure stakeholders are involved, and appropriate measures should stakeholder involvement begin to fail.
2. Budget problems. A correctly selected project management methodology will put the right emphasis on budget analysis, and will provide the right tools to stay on top of the budget. The project manager may need to look outside his or her own skill set to manage to those requirements — but the methodology will establish the goals, the tools, and the metrics from which deviation triggers a red flag.
3. Poor requirements. The right project management plan will include appropriate methods, probably mandated as part of a technical requirements standard, for developing strong requirements. The plans will include adequate validation and verification of requirements — possibly through strong quality assurance measures. Again, all of these tactical solutions will become part of the project and solve the overarching problem.

So, the root cause of project failure — in fact, of 69% of project failures, according to KPMG’s study — is failing at the strategic level to identify and implement appropriate project management practices.

This means choosing the right standards and methodologies for the project. For instance, if tight quality and budget is a concern, more rigorous controls in this regard are needed. That probably means shunning simple methodologies such as lightweight, agile methods in favor of something that uses more ceremony and process (such as that defined in the PMBOK® and other classical project management approaches). It also means sticking to your guns and making sure the methodology is applied. Showing the methodology to the team and putting it on a bookshelf won’t cut it. Application is the key, and that means recognizing that the standards, practices, and procedures are there for a reason — don’t take shortcuts, because doing so means introducing risks to your project’s health.

Related posts:

1. Doing away with ineffective, broken risk management
2. Managing risk in global projects
3. Tackling the global project problem

Every individual is different, and every situation is going to require a different response. Temper tantrums, sexist remarks, chronic lateness, information hoarding, playing favourites … people don’t always behave themselves at work. An adept manager needs to understand the individual nuances of the situation and act accordingly. You need finesse, insight into your team, an understanding of psychology, and often, incredible patience. Here are a few strategies that I always like to try.

1. Engage the malcontent

Quite often, the negative attitude comes from feelings of being disengaged from the team or the project. Perhaps the individual thinks he could do the job better; perhaps he isn’t working on what he wants to work on; or, just feels the project is heading in the wrong direction. Most often negativity stemming from these problems will surface in a team setting, such as passive aggressive behavior, grumbling, openly showing dislike for decisions. I like to engage this individual in finding a solution. Hand accountability to that individual and, in essence, give full reign to fix the problem. With accountability often comes responsibility — and the need to realize that decisions are not always quite as simple as they appear on the surface. Of course, sometimes the individual makes a mistake — but in this case, the lesson is still learned. They “get their way,” but also find out that “their way” wasn’t, afterall, the right way. Of course you’ve got to strive for a better outcome — assign responsibility, and then back them up. Make sure they’ve got resources and help in the decision making process. Hopefully it becomes a learning experience for everyone.

2. Reach consensus

Sometimes it’s not practical to let an individual run with their own ideas. Yet, still you have someone that feels “things” are heading in the wrong direction. I like to try to reach consensus or, failing that, at least agreement that we’ve made the right choices given what we know. One approach is to schedule a round table with the malcontent and his peers, perhaps 3-4 people. Discuss the problem, and try to reach agreement on direction. In the best case, his peers will sway his opinion. More often, the complexities, choices and decisions that have led to the current situation will be discussed — and the “black and white” situation fades in favor of many choices, and trying to make “the best one.” With a little luck, the malcontent employee walks out of the round table with two things: 1) a sense of having been engaged in the decision making process and 2) a new appreciation for the complexity at hand, and the decisions that have been made.

3. Make it clear that it’s a team effort

A one-on-one discussion goes a long way. Spend some time with the individual and really try to listen, and understand what the problem is. Come up with some mutual objectives — some things for the individual to work on (these might be soft skills, such as being less negative) as well as some things for you to work on (these will be things to help ameliorate the bad attitude, such as making sure his opinion is part of the decision process). Make sure it’s mutual, and show some real effort here — there’s tremendous value in demonstrating how much you value each individual’s contribution. Work with the individual to address the problems and find solutions.

4. If all else fails…

If you still have a problem employee on your hand after making a sincere effort to fix the problem, you’ve got to make it clear that continued negative behavior will not be tolerated. You also need to be prepared, so document the problems. Keep a record. After some time, it will become a matter of reprimanding and giving specific, required objectives. This is the worst case scenario and more often that not, the first step toward losing an employee. Sometimes it’s a “wake up call” to the individual, but often this kind of heavy-handed approach just feeds the negativity. Be prepared for either outcome.

Wayne McHale was a senior manufacturing executive when he heard reports that one of his branch offices was getting fed up with the arrogant, condescending attitude of a new manager. He decided to pay a personal visit to the office and put an end to the situation right away. “I made it absolutely clear that while we were delighted to have him on the team, certain behaviours could not be tolerated in a team environment,” says Mr. McHale. “He was taken aback, initially, because I think the behaviours were somewhat ingrained. He was a star and had been told for too long that he was wonderful.”

Whatever the case, make sure you have a good documented history. You can use it when talking about the problem with the employee, making sure you have concrete references to poor behavior. In the worst case situation, you can also use it to back up termination papers.

Above all else, don’t be an enabler

Some organizations actually nurture bad behaviour, according to Lew Bayer, president and CEO of Civility Experts Worldwide. For example, an all-star employee with a primadonna attitude may be tolerated because a manager decides it’s too costly or too much hassle to seek a replacement. Or perhaps certain rules may not apply to someone who has formed a friendship with a senior manager. In situations like this, it’s often the boss that’s the problem.

You can’t avoid dealing with workplace performance issues — it will come back to haunt you in the long term. Perhaps other employees will get fed up and quit. The problem employee might have a temper tantrum in front of a client. It’s hard to predict but one thing is almost certain: It’s going to happen at the worst time, when stress is high and a lot is on the line. Ignoring the issue won’t make it go away; it will just get worse.

Don’t wait until the problem becomes a problem for everyone. Be proactive, and recognize that the workplace is above all a place for professionalism. If your star performer is worth keeping, coaching can help. If your disaffected team member needs to feel involved, a few changes can make that happen. But, only if he’s open to the idea. If not, it may be time to take more direct action in order to preserve the integrity of your team.

Related posts:

1. When there’s a freeloader on your team
2. Team-based performance is key, but only works with team input
3. Managing with blinders on

I think the most valuable asset a Software Tester can have is an attitude of gleeful problem discovery. Someone that loves to break systems, discover their imperfections, and explore their weaknesses makes a great tester. I haven’t met many people that really enjoy and excel at this, but it’s probably is an attribute that is common with Hackers as well.

It’s also wonderful to have a tester that really cares about the quality of the product. It’s absolutely essential for someone that wants to excel as a tester. That means having the patience and desire to work closely with the Quality Assurance group, to understand what a “good customer experience” means, and to really grasp things like quality of services, user experience, and customer needs.

Part of being a good tester means enjoying running down the rabbit hole. Where the hole leads is a mystery. Perhaps testing discovers problems stemming from poor UI design, SQL injection problems, performance issues caused by heavy loading, or playing the clueless user that always clicks the wrong thing and triggers a logic error.

The “how” of testing is another matter though. Yes, there are well understood principles and techniques, and often tools, for testing all of these things. I have found that in most cases, good testers tend to specialize. I don’t expect to find one person that can find the flaws in the user interface, perform load testing, and also look for SQL injection vulnerabilities. To get really good at all of these things, you need a team — some of those team members will focus on the back end, some on security, some on database systems, some on the front end. Finding someone that’s great at tackling a couple of those verticals is pretty rare. That said, every tester should have an adequate, at least shallow understanding of all of these areas. In order to properly localize a problem, you need to understand what could be causing it. But having other resources to bring in to help diagnose the specialty areas is critical.

Related posts:

1. Exposing the enterprise to risk: Who decides what not to test?
2. What do you mean, SQA isn’t testing?
3. Quality assurance as a way of life

Organizations facing these environmental issues need to put a considerable investment into mitigating the associated risks. This is essentially why the “promise of outsourcing” has been toned down over the past decade: Gone is the illusion that you can get solid work for 25 cents on the dollar. “Real” outsourcing costs tend to range anywhere from 70 cents on the dollar to $1.20 on the dollar (yes, outsourcing can often lead to higher costs — but sometimes it’s not just about cost, but geographic presence, distribution, foreign market penetration, etc.)

Language barriers pose some of the most difficult issues to work around. Being unable to easily communicate means poor communication becomes a barrier to the entire team. This can lead to misunderstood requirements, misinterpretation of directions, even a complete disconnect on whether a team is in trouble or doing fine. Ideally, open communication, information radiators, and visibility are central to successful projects. Any barriers increase risk, and that means increasing efforts to compensate. Closely related to language barriers are cultural barriers. A pretty obvious example is the straightforward U.S. business culture in regard to the respectful and tradition-rich Japanese culture. Even seemingly similar cultures pose barriers; for example, East Indian cultures and U.S. cultures don’t easily connect until interpersonal barriers have time to break down.

Business environment and common bias also contributes to the risk of disparate teams, especially those separated by business culture. For example, consider a client developing a legal work product solution in the U.S. market while using East Indian resources. The lack of a common business foundation can easily lead to a complete disconnect regarding assumed business objectives (in other words, the legal system is very different in the U.S. versus India, which means a lack of common understanding regarding some pretty basic business goals).

All of these issues can be mitigated with appropriate practices. The necessary measures will vary from one project or organization to another — there are a lot of variables at work, and that means every project has to be treated uniquely. The common thread is communication. Breaking down these barriers by using process, technology and culture is critical. The disparate team needs to become one team, working as a unit — and that usually means a significant investment in tools, strong processes and team-building exercises. I strongly advocate rotating team members across the organization or project as one example. This helps across the board: It breaks down communication and culture barriers, helps team members get to know one another, lets distant teams experience local culture, and helps to build a collaborative “whole team.”

Related posts:

1. Tackling the global project problem
2. Tackling the global project problem, part 2
3. Fix your boss (or, reduce risk to quality using a matrix approach)

We all want to be Apple. We want to have their reputation, at any rate. A zealous customer base, fantastic products that seemingly flow out of design and into production without a hitch, and a virtually zero record of recalls or product delays.

But it’s the part about the customer that really grabs our attention. So the question is, how do they do it? If we put the right people in a room together will they just “get it,” and execute a flawless vision?

That’s likely a key part of it, at least in so far as it takes the right people to make the right decisions. But how do we execute our vision with such precision? And if we look at other successful companies, will we find some theme that’s in common with Apple? Absolutely. That common theme isn’t just one thing — But every single successful company has one common element in their strategy: A mechanism for avoiding undue risk.

Risk management has become mainstream. It’s no longer the domain of rocket scientists and actuaries. In fact, it’s become so mainstream that formal risk management practices are showing up everywhere we look. Most of the time, we’ll see the word Enterprise included in the definition — a way of letting us know “this is for the whole firm.” Enterprise Risk Management (ERM), Business Continuity Planning (BCP) and Governance and Risk Compliance (GRC) are just a few of the different names risk management flies its flag under.

Is More Attention A Good Thing?

But is all this sudden attention to risk management going in the right direction? To answer that, we need to look at the specifics of different risk management techniques.

For example, the Project Management Institute (PMI) and National Institute of Standards and Technology (NIST) have both put forward standards that devote significant space to the topic of risk management. The PMI standard of risk management (PMI-RMP®, or Risk Management Professional) includes some pretty extensive methods for identifying, quantifying and mitigating risk.

Much of the PMI-RMP standard can be considered a brief introduction to risk management. It doesn’t introduce quantitative analysis or provide any background of Judgement and Decision Making (JDM) theory. It does, however, provide a starting point, some kind of a baseline that we can use to at least make sure that our projects, programs and organizations are addressing risk management — at some level.

This is good, at least at first blush. But, unfortunately, when we dig deeper there could be a more subtle problem here: The practices advocated by PMI and NIST standards are, quite simply, apt to cause more harm than good.

Worse Than Nothing

There are decades of remarkable research in JDM and risk management theory. The research that has gone into this kind of theory has produced an invaluable treasure trove of tools, processes and techniques that we can leverage to learn how to accurately and effective assess risk across our organization.

This same research has also largely debunked “crackpot” risk management theory and poor decision making practices. For instance, Harvard Business Review led a study of over 200 popular management tools, like TQM, ERP and so on. Independent external reviews of the degree of implementation of each of these various tools was compared to stakeholder return on investment over a five year period. The resounding conclusion from this in-depth study, as reported by HBR, was that: “Our findings took us quite by surprise. Most of the management tools and techniques we studied had no direct causal relationship to superior business performance.”

But this shouldn’t be a surprise, at least not to anyone familiar with formal risk management and JDM theory. In research conducted over many decades, such as that of Brunswik, Kahneman, Hubbard and others, most of these recently introduced management practices have been exposed as ineffective and often even harmful.

Consider, for example, the principle method for quantifying risk in the PMI standard is a matrix-based weighted scoring system. This system advocates highly subjective risk assessment practices, such as relying on risk assessment almost entirely from subject matter experts. Studies have shown that even well trained experts — let alone the people that often serve as experts on review boards — tend to provide highly inconsistent and spotty assessment results. One study by Hubbard tested a group of experts in their ability to assess risk across a portfolio of projects. Unbeknownst to the participants, two of the assessed projects were identical — and, hence, we should expect identical risk assessment of the two projects. But that’s not what the study shows: Participants only agreed with their own risk assessment 22% of the time. The rest of the time, risk assessment varied widely, sometimes as much as 35% by the same individual.

Fixing It

Of all the professions that practice risk management, actuaries are the only ones that can claim a real profession. Actuaries, much like accountants, doctors and scientists, must demonstrate their ability to assess risk using scientifically proven methods. And, like other formal professions, an actuary puts her license on the line when certifying a Statement of Actuarial Opinion. As with doctors and lawyers, if she loses her license she can’t just get another job next door. The industry of risk managers, modelers and assessors outside of the insurance industry would be greatly served by this level of professional standards.

Likewise, organizations such as PMI and NIST should stop promulgating what amounts to crackpot risk management practices. Decades of extensive study have shown that the core principles of risk management integrated into the PMI and NIST standards simply do not work. Worse, in many cases these practices actually cause more harm than good. Scoring methods should be disposed of. Instead, standards should rely on existing bodies of proven risk management and JDM practices.

But in the meantime, attaining a greater awareness of the risks associated with bad risk management practice is our responsibility. Understanding what to look for in risk management, and consulting trained professionals that can employ statistical risk methods is a good starting point. At the very least, firms should consult with formally trained professionals — and look for empirical, statistics-based methods. Anyone proposing a weighted scoring system should be shown the door!

If you would like to learn more about risk management theory and practical methods of assessing and avoiding risk, see Hyrax International’s seminars on these topics. Attendees are welcome at public presentations. If you are interested in hosting a presentation at your firm, contact Hyrax International directly. Introductory seminars are offered at no cost.

Related posts:

1. Managing with blinders on
2. Managing risk in global projects
3. Fix your boss (or, reduce risk to quality using a matrix approach)

In some cases the departure of these senior employees will allow younger managers to step up to the plate to fill the void, but not everyone is ready, or even wants the next rung on the corporate ladder. So the question becomes:  After all you’ve gone through during this recession, can your organization survive the holes these departures will create? Do you have a well developed Succession Plan with Knowledge Transfer processes in place?

Many managers faced with a looming shortage of employees have reconsidered their business model; to find alternative ways to serve the client, build their products, distribute the materials, but a reinvention of their strategy simply brings new challenges to the fore.

Take the case of one of our clients who decided to outsource some aspects of their work to deal with looming labour shortages. They were in for a nasty surprise. A few months ago we conducted a risk assessment and  they found to their horror that not only were their boomers poised to flee, so were some of their specialists — the “go to” people others rely upon to do their work.  The newly outsourced work was what these ‘specialists’ enjoyed, so instead of taking on new responsibilities, which were less appealing, they were seriously considering offers of work at the outsourcing company! Clearly a game plan was required to stall a potentially disastrous situation.

Traditional succession planning identifies high potential employees and implements long range plans to develop those people so they are well equipped to lead in the future. The focus is on core competencies, business knowledge, technical skills and sound judgement that will lead to solid business decisions. Mentors are enlisted from the senior ranks to pass on savvy business knowledge to new incumbents. Short term overlaps are permitted so a veteran of the job can coach a neophyte.

But what can a company do when the mentor has retired or the specialist now works elsewhere?

How can crucial knowledge be retained for organizational health and continuity?

Knowledge Transfer has become the latest ‘buzz’ as leaders, faced with the loss of people and corporate knowledge, struggle to retain information that is vital and which has contributed to their present success.

New people to the company don’t know what they don’t know, so important questions are not asked. The soon-to-retire employees who have been operating smoothly for years; often don’t know what is vital — what to keep or toss — and the clock is ticking ever closer to their departure. Some, on the other hand, know exactly what to hang on to for that lucrative consulting job they envisage after their retirement and guard it jealously from their colleagues for fear of losing their distinct advantage.

So, getting vital knowledge from individuals and passing it to the right people, in a way that can be understood and assimilated quickly and accurately, is the challenge that will be facing most business leaders for the next two to three years.

We suggest you implement a few simple things to protect your company from a major risk.

1. Pinpoint how many people will be leaving within the next three years and develop a strategy to capture their knowledge now before it’s too late.
2. Identify who your Subject Matter Experts (SME’s) are and determine their unique advantage — what makes them so valuable to your organization?
3. Consider doing some serious cross training to reduce your vulnerability, build capacity and engage employees in building a better workplace.
4. Develop a data base with SME’s, lesson’s learned and past practices so people can source information as and when they need it.
5. Start a community of practice so people are encouraged and supported to share information freely with colleagues.
6. Reward people for building your internal capacity when they mentor, coach or lead information sessions.

If you pondered for a minute when you might get around to this — stop thinking — start taking action now, the days, months and years are slipping past very, very quickly. Is your organization going to be a risk?

Heather Hughes, CMC is a Certified Management Consultant with a 30 year international track record. She specializes in building vibrant organizations through Leadership Coaching, Succession Planning, Knowledge Transfer and Employee Engagement.

Related posts:

1. Bad employees rarely quit and good ones are hard to find
2. Fix your boss (or, reduce risk to quality using a matrix approach)
3. Tackling the global project problem

Good employees are really hard to find — A solid worker isn’t just difficult to find, he or she is really difficult to find. And they’re the first ones to leave. The truth is that 10 percent of the world is competent – and you’re looking for that 10 percent in every hire.

It’s hard to do consistently. And that’s why organizations that do it with frequency have such strong reputations. If you want to build a business predicated largely on finding, getting and keeping quality employees to succeed, you should understand that premise will be your greatest risk. Finding a market and profitably selling to it (usually the greatest risks) will take a back seat. Better yet, pursue a business that needs some reasonable percentage of employees to be really good.

But if that news isn’t bad enough, consider the other side of the coin — if you don’t have really great employees filling your ranks, then what do you have?

Your bad employees rarely quit — For one thing, poor performers aren’t really all that motivated to look, as that might involve actual performance. For another, no one else is likely to recruit them. Your marginal and weak employees are with you for life unless you move proactively. In many years of running businesses, the only time this wasn’t true was during the dot-com bubble. At that time, every idiot could get a 15 percent to 20 percent raise here in Northern Virginia by changing jobs. And they did. Aside from that blessed time, weak employees are your most “loyal.”

Don makes a good point, among several others (his article is 8 things I wish I knew before starting a business): Having, and holding on to, great employees is very, very hard work.

It’s also quite possibly the one sure-fire factor that’s going to push your company toward success. Consider a few of the leaders in the technology industry, such as Apple and Google. Both have stringent hiring processes and focus on the quality of the hire first, and growth second.

Let’s put it another way: Does it make sense to focus on growth if what you are growing is mediocre (or worse)?

Related posts:

1. Hiring for the culture
2. It’s never a good time for training
3. Articulating the value of training

So is Agile just hype or is there something to it?

There are strengths to the agile way of thinking, and many of them bring useful perspectives to software and systems development that are new and even revolutionary. Here are some of the things that work — and, potentially, that radically change our old-world practices.

Whereas most legacy methods stem from industrial process — that is, assembling a product using a set of defined, predictable steps — the agile method is empirical. It recognizes that development is more like invention and research, more akin to scientific study, than assembly. This empirical nature is at the heart of the agile mantra: Deliver, measure, adjust and repeat. The strength of this approach often bears itself out in fantastically hyperproductive teams that deliver working product far more quickly than legacy methods, such as waterfall, could ever achieve.

Agile does this by cutting through complexity. Every agile-based methodology focuses on simplification of otherwise complicated problems. For example, XP and Scrum both emphasize development of near-term, complete deliverables. This means carving out tangible and reasonably independent pieces of work, focusing on that work, and then — at least as much as possible — moving on to other work. This approach requires that large, complex problems are broken down into manageable pieces and thought of on a micro-deliverable level. Likewise, this approach minimizes ceremony and eschews as much procedure as possible. Some agile methods go to extremes in this regard, focusing entirely on delivering work product and not at all on procedure. This translates into minimizing complexity on a large scale.

Closely related to eliminating complexity is agile’s focus on progress measurement. Most agile methods measure progress chiefly, if not exclusively, in terms of delivered work product. Most methods also are quite stringent in defining progress only when finished work is delivered, which means you can’t work for nine months on a single big feature. Instead, micro-deliverables target key features, deliver those features into the customer’s hands, then moving on to new features. This can be a huge strength because the customer gets working product in-hand to review early, and often. It involves the customer early in product evolution, leading to a host of benefits including better product targeting, prioritized development and improved quality.

These characteristics of agile methods combine to fundamentally change the way software and systems development is practiced. Agile also empowers individuals to become stellar performers. In fact, all forms of agile rely on this to some degree — with more lightweight agile methods being completely dependent on individual empowerment. The idea is that an empowered team will leap over constraints to get the job done, no matter how “out of the box” the thinking needs to be. It’s a refreshing concept and one that can indeed be supremely successful, but it does require the team to embrace the idea wholeheartedly.

Another benefit, at least in some situations, is the creation of self-organizing teams. Partly because of the light ceremony, the fast pace, and the penchant for empowerment and accountability, teams become self-organizing. This works when the team has the right make-up, as individuals step up to take on tasks best suited to individual skills. Self-organized, empowered teams become very powerful and very productive, provided that the team members are up to the job.

There is absolutely no doubt that agile methods make it possible to get things done quickly. That’s what it’s all about, after all. The real question to me is how much of this tradeoff is really desirable? How often do we want to eschew process and maturity in favor of getting things done quickly?

More importantly: Can we effectively merge the best attributes of Agility with the most valuable benefits of established processes and standards?

Why Agile doesn’t work

When an agile project fails, it generally does so spectacularly and predictably. The common failings of agile-based projects are just that… common. We see the same problems over and over again, and this has become the basis for many critiques of agile methodology. After all, if we keep seeing the same problems crop up again and again, isn’t this proof enough that the process is flawed? This becomes clear in hindsight, so why do we continue to see 90 percent of projects missing the mark?

The fact is, agile by itself is just one tool in the toolbox that should be applied with other implements of the trade. In my experience, the problem comes in most often because small- and mid-sized organizations experience brilliant success with agile and then assume it can work everywhere. They throw out the toolbox (or perhaps never buy one in the first place). Yes, agile can succeed. Yes, it can deliver fantastic productivity and stellar results. But not always — in fact, I will go so far as to say not often.

This isn’t because of agile’s limitations. Instead, it’s because of overconfidence by those putting it to use, and the mistakes an immature organization makes as it grows and applies it inappropriately.

Immature companies and teams are cutting their teeth, again and again, on the limitations of agile.

All agile methods make it easy to oversimplify complexity. In fact, agile’s strength of eliminating complexity might be better stated as “ignoring complexity.” There are appropriate situations for this but, more often than not, ignoring complexity leads to problems. Most business cases don’t call for undefined delivery dates or loosely changing requirements and partial deliveries. These are risks that most business models are incompatible with. If the risks aren’t something that your business can sustain, adopting a purely agile process is taking a huge gamble.

Likewise, focusing on the near-term is an agile attribute that introduces a lot of unknowns into the business-end of an equation. Few people will contend that agile is appropriate for mission critical efforts such as, say, launch vehicle development, as sometimes requirements need to be set in stone before anyone starts development. But what about situations where some degree of fuzziness is acceptable or even beneficial? Agile advocates compatibility with change, sidestepping change control procedures that would otherwise place tight controls over requirements. Requirements change carries with it a heavy burden, particularly when it comes to the cross-organizational impact to marketing, budget, quality management and the customer. However, cutting change control, requirements management, and configuration management from the process can lead to long-term disaster that the short-term perspective of most agile methods will overlook.

This theme of reducing structure and control has cut out many waterfall-origin processes. The danger often manifests as small-scale agile projects are successful, leading to wider-scale adoption of agile. But, as the projects grow in complexity and criticality, major missing components in the process become evident. For example, no agile methods today integrate comprehensive quality assurance procedures (in fact, thanks to some early mistakes, such as MIL-STD-498[#], most people think quality assurance is software testing — it’s not). Structured software testing often becomes an afterthought, and risk management programs tend to be regarded as “fuzzy disciplines.” Yet, these are the processes that successfully put man on the moon, that develop health care and financial services systems, and ensure that nuclear plant regulatory systems don’t fail after delivery. Of course, there is a cost to each of these processes, and every business needs to weigh the cost-benefit of adopting more process against cutting those processes. This needs to be an on-going evaluation, made as projects, organizations, and teams evolve — it’s not a decision that stands alone.

From a purely hands-on, management level, agile methods pose “people problems” as well. The strong emphasis on self-organization and empowerment can easily backfire. The former relies heavily on people that are capable of self-management and self-direction. Not everyone can live up to that expectation. The latter, delivering empowerment to the team and individual, can lead to a hero mentality and silo’d teams that refuse to play well with others. As projects grow in size, complexity, and dependency on other teams and resources, these characteristics become the drawback of an immature organization.

Almost all agile methods oversimplify valuable processes. In some situations, the project survives the oversimplification. Sometimes the business is tolerant of the fallout. In every case, agile methods expose the project to risks that stakeholders should be — and often are not — aware of.

What to do about it

We need to be cognizant that one solution does not fit all problems. While an agile method such as XP or Scrum may have led to success in one project, this doesn’t make it a foregone conclusion that it will do so again. Each project is different, and organizations evolve over time. Adopting one process to solve all problems is a sure recipe for failure. On the other hand, having a well-versed team that can draw on several methodologies, as appropriate for the job, is a recipe for success.

If your organization is looking for the one-size hammer to hit every nail, make sure it’s as configurable a hammer as possible. Don’t choose something that is either too lightweight, such as XP, because many projects will overreach the capabilities of such a lightweight process. Likewise, don’t try to implement a full-on waterfall style methodology either because, while definitely thorough and capable of getting the job done, it’s just overkill for many smaller projects. If you must choose a single process, pick one that’s efficient, borrows from both agile and waterfall, and is highly configurable, such as Rational Scrum or the Rational Unified Process. Both of these have the maturity to deliver large-scale projects, but also support starting small and adopting minimum ceremony.

A better awareness of what specific agile practices can and cannot accomplish is key. For example, Scrum is not a development methodology, and it cannot effectively deliver software or hardware projects unless it wraps itself around one. Yet today many organizations are employing Scrum as if it were a development methodology. I’ve even seen an organization of several hundred developers “force fed” Extreme Programming from the top down. The outcome of that particular operation: Mid-level management hid the fact that they didn’t use XP from top-level management after everyone realized what a mistake it was. Perhaps we’ll have to wait for mature standards in education and certification to evolve, but personally I’m not sitting idly by.

One of my personal pet peeves in the technology industry is a relative lack of standards and qualifications. Would you go to a doctor that didn’t have a medical degree? Would you hire an architect that didn’t have an appropriate engineering degree? Yet we hire software professionals (much less often hardware professionals) without adequate education, current qualifications, or meaningful certifications. For that matter, the proliferation of meaningless qualifications (such as Scrum Master certification) continues to weaken the industry. In the long run, we need better standards regarding education, accreditation and certification.

Understand agile methods for what they are. Keep in mind that lightweight process carries risk. Use the right tools in the right situation.

Coming full circle

If we add all of these things to agile methods, won’t we just end up using waterfall process all over again?

I don’t think so. Waterfall-based process, the original behemoth processes born out of industrial process, are widely recognized as inefficient. There are tremendous advantages to pressing forward with a merger between waterfall practices and agile practices. I hope the end result is a new generation of software and hardware development methodology — a generation that we’re just starting to see as processes such as Rational Scrum come to the fore. It’s time for development methodologies to evolve, and there’s no holding that back.

Related posts:

1. Making Scrum work: Common failings in adopting Scrum
2. Scrum is not an agile methodology
3. Common oversights in choosing methodology

Probably the most difficult situation is the latter — a boss that’s too hands-on, or perhaps an external resource that is too busy, yet absolutely must approve every decision. The story usually goes something like this: He’s a great guy, pretty easy to get along with when it comes right down to it — but he’s also insufferably “hands-on.” He’s just got to review every critical decision, contributing, fine-tuning and tweaking until it’s just right. This micro-managing mentality is causing all kinds of bottlenecks: Decisions are held until the last moment, changes are made late in the game, and your entire department suffers — staying late to “catch up” after your boss delivers his final word on any given issue. But here’s the real kicker: He’s good at what he does, and even though it creates internal chaos the finished product is that much better for his input.

Consider the image to the right: A critical “quality spike” representing the single project resource that is overloaded. This resource does raise project quality, but the spike also represents a huge bottleneck to the project.

Your department has tried everything: Getting him involved earlier in the game (it doesn’t work, his schedule is booked and it always presses to the last moment); Involving other review sources so your boss’ input is minimized (that helped a bit, but the other sources don’t like it when your boss overrides their contribution); You tried publishing the “departmental cost” figures that show all this inefficiency (but the powers-that-be seem to feel this is “just the cost of doing business”).

This is not a simple problem. It gets right to the root of the dynamics created in working teams. How can the situation be improved, realizing positive gains in a habitually entrenched process that some recognize as painful, but overall is regarded as good enough?

There are really two issues that need to be dealt with here. One is obvious, one perhaps a little bit less so. Most strategies up until now have focused chiefly on the primary goal:

“How can we minimize the negative impact of a critical resource (our ‘hands-on boss,’ for example) that doesn’t work efficiently with your team?”

The problem with this approach is that it attacks an entrenched problem head-on, and often does so using a single head-on approach to solve the problem. When an attempt fails, that approach is discarded and another tried. The principle flaw here is that each attempt to solve the problem is, in and of itself, not effective enough to get the job done. A secondary flaw is that each separate attempt tends to get lost in the chaff of day-to-day operations. We all know there’s a problem, but nobody is really tasked with studying it, compiling the entire scope of the problem and its impact, and somehow bringing about a solution.

For example, when your department produced some figures on costs to the organization, those figures clearly showed that, through inefficiency, rework, and last-minute changes, your team suffered. You even went so far as to tie it to actuals, a dollar figure that represented all that overtime and rework — but, it was accepted as “the cost of doing business.” Since it didn’t work, it was discarded — but the fact is, it’s only part of the overall puzzle.

So the head-on solution won’t work. Let’s consider a more subtle approach to the problem:

“How can we make the critical resource less critical?”

This would achieve the same result, but it’s really an entirely different problem — one that can be attacked somewhat obliquely. Rather than focusing on how to change the way your boss works (aka “the critical resource”), try focusing on changing what your boss needs to work on.

The first step toward a solution is realizing that solving this problem is a project, just like any other. It needs a project lead and sponsor. It needs to be handled as an iterative project, and the team needs to recognize that incremental improvement toward an ideal is acceptable. You aren’t going to discover a single silver bullet that solves the whole problem — that’s just not the nature of human team dynamics.

Make it a project initiative

Once your “quality improvement project” is up and running it will snowball. Here are a few steps that will get the ball rolling:

1. Initiate the project. Don’t think of this as a “workplace problem” that needs to be fixed in the short term. Instead, create a project initiative around it and get some mindshare going. Someone is going to need to lead the project, even if it’s unofficial — that person will keep the forward momentum.
2. Focus on making many small improvements across the board. For example, in the case I described above, consider how involving other review sources did in fact help, but not always. That’s an incremental improvement, and it raised the quality of the project a little bit.

Now, consider the impact of this approach over time. If numerous improvements can be implemented, and each one raises project quality just a little bit, it has an inevitable outcome: Your boss is going to have less to worry about, and less to be involved in. This is shown visually in the second image — as the overall quality matrix delivers improvement across the project, the “critical spike” that represents your boss’ workload begins to shrink. This is a quality matrix at work.

The goal is simply this: Dilute the need for your boss to be involved in every decision, by raising the bar in as many places as possible. You will gain a “double whammy” by not only reducing the amount of work he needs to contribute to, but also by increasing his own efficiency since he’ll have less to worry about. The bottleneck will begin to dissipate.

Assemble your team

Get involvement from everyone that’s affected by the problem — your team, your peers, other departments that might be affected. Of course, part of the finesse in this kind of project is to make it clear exactly what problem you are solving without making the project sound subversive or offending the wrong people. Your boss may be a terrible bottleneck, but also remember how valuable he or she is — this isn’t about cutting him out of the picture, going around him, or changing policies you don’t like. It’s much better to focus on things like qualitative improvement, streamlining projects to avoid inefficiency, or developing lean principles. Make it positive, in other words.

Identify key risks

Your probably already know what the main pain points are. Your team experiences them all the time: Loss of productivity, overtime, last minute changes, introducing new errors, reworking something that could already be finished. These are the lesser symptoms of an endemic problem: What are the potential risks if the problem goes unaddressed? Certainly continued loss of efficiency, higher expenses to the company and lower employee satisfaction come to mind. Perhaps there’s even a trend of some team members transferring out of the department to find a better working environment. More dramatic effects can include missed product deadlines, problems with released products or lowered perception of the department’s attention to quality. All of these can have a real financial impact on the company.

Identify those risks that are most significant. Those should become the focal point for initial improvement. This is a “risk driven” model, where high risk is identified — in other words, the most painful or potentially painful result of the problem gets the most attention as early as possible. Generally it’s best to tackle a few things at a time. While the list of risks could be very long, if you try to solve every problem at once it’s going to be overwhelming.

Mitigate

Once you’ve identified the top few risks, pull together your project team and identify candidate solutions. You’re designing something new here, so it’s going to seem like brainstorming — which is exactly what it is:

1. Can more attention from outside experts improve the overall product, lowering your boss’ need to be involved?
2. Would the quality assurance organization be a helpful partner in achieving this?
3. Could changes in the project timeline better accommodate your boss’ hectic schedule? Perhaps driving for earlier involvement (or longer project schedules) would help.
4. Can the team multitask, effectively putting several critical paths into play so that if one gets stalled waiting for your boss, the others move forward?
5. Would better tracking systems and information management help solve the problem? Perhaps your boss would benefit from a system that brings more organization and immediate answers directly to him.
6. Perhaps greater visibility into the project timeline and reasonable deadlines would both improve responsiveness and provide some firm schedule guidance.
7. Information radiators (such as task boards, timelines and assignment lists) might help keep people up to speed on overall project status (and what has moved from “medium” to “high” priority).
8. A widely accessible system that assigns tasks and prioritizes those tasks would increase visibility of current goals as well as get everyone united about what needs attention first.

Every organization is going to discover different solutions that help its specific situation. It will likely take time to hit on the first few steps that move in a positive direction — but those are the ones you want to hang on to.

Include a quality improvement element

Organizations that have the benefit of a formal quality assurance and improvement group should try to leverage the group’s knowledge. Quality assurance is about auditing and measuring progress toward improvement. Most quality assurance groups tend to be very good at measuring improvement over time, and putting that knowledge to use will help in gathering metrics and identifying what’s working, and what isn’t.

Track your progress

Measure, act, measure again, and adjust. This is the heart of most agile development methodologies — and most scientific methods.

The most important thing to do is realize when improvement has taken place. That means tracking information — metrics — about your organization’s efficiency. This can seem pretty amorphous when dealing with a problem such as this. Remember that it comes down to improved efficiency of individuals. Some teams will have simple metrics that are easy enough to track, such as number of projects completed on a monthly or quarterly basis, or number of cases filed. When all else fails, the number of hours committed to rework is a great metric, because it tracks directly to risk identification and mitigation up front. That is, if you properly identify a risk and mitigate it early in the project, the amount of time spent in rework related to that risk goes down.

This is one reason it’s important to have everyone affected by the problem involved: It’s going to require everyone to look for these signs of improvement. It might even require tracking hours spent in rework. Fortunately, with the goal in sight (less time spent reworking and fewer overtime hours) it shouldn’t be too hard to commit people to some moderate tracking.

Gather metrics on what works and what doesn’t work. Emphasize incremental improvement as a desired outcome: Track the results of each effort, and keep the best practices. The important thing here is to demonstrate improvement over time, so that everyone sees each action as contributing to the solution, not as a failure in delivering the end result.

One of the most important goals in creating a project mentality is the positive group effect. Seeing each practice as part of a solution keeps it alive — as opposed to trying something and perceiving failure. As the team, department or company works together to deliver a solution it becomes a self-reinforcing effect. Even your boss might notice, and actively start to take part.

Related posts:

1. Managing risk in global projects
2. Successfully applying lessons learned
3. Quality assurance as a way of life

1. Quality Assurance is responsible for auditing and ensuring all aspects of work meet agreed upon quality standards.
2. Therefore, if QA is also responsible for Structured Software Testing, who is going to audit the testing team for compliance and quality of deliverables?

Quality assurance is the “cop” that makes sure we all do our job right. It has the authority to say “hold it, something’s not right.” Testing is the organization that performs regression analysis on a product to see if it works right. The skills required for these two disciplines are dramatically different — as much as business management and programming.

The value in a QA organization is that it is independent. It focuses entirely on ensuring quality across the organization. Would you want development, project management, requirements management, configuration management, verification & validation, customer service or any other project discipline to report to QA? Why should testing be any different? The bottom line is simply that if testing reports to quality assurance its independence is compromised — the organization becomes vested in representing testing in the best possible light and, just possibly, taking shortcuts or letting a few things slide.

I realize that a large segment of the industry seems to use a different terminology, lumping testing under quality assurance. It’s unfortunate, because doing so handicaps both organizations. It’s important to realize the difference between the activities of ensuring quality in a project (largely focused on standards of process), and fault testing (activities that perform hands on fault detection and diagnosis).

The activities of quality assurance focus on things like quality assurance plans, project audits, requirement audits, checklists, enforcing standards and process, checking the results and deliveries of different teams, and discovering discrepancies between requirements, project artifacts, and functional goals. Quality assurance, as a general rule, spends more time looking at what the project teams are doing, performing audits on the work generated by each team, and figuring out what hasn’t been done according to agreed upon standards.

Testing, on the other hands, focuses on test planning and management, test case development, test execution, regression analysis, performance testing and defect diagnosis. These are “hands on the software” activities and much more akin to programming than auditing. Indeed, with today’s testing tools and complicated programming environments it can be a very “in the code” experience.

Keep your organization healthy and your teams focused on their competencies. Don’t disregard the value in centralizing authority for specific roles with specific teams — it lets them do their job well, without distractions and without muddying the water with conflicting interests.

Related posts:

1. Exposing the enterprise to risk: Who decides what not to test?
2. Quality assurance as a way of life
3. Scrum is not an agile methodology