Tag Archives: Standish Group

Standish Group: the 21 perils of using consultants

By David Bicknell

We always have a lot of time for the work of the Standish Group in the US on how and why IT projects fail.

The group’s recent Chaos newsletter makes some strong points about the perils of using consultants. (In fact, in all, it identified 21 perils!)

Standish argues that the number one consultancy misdeed is what is describes as “the X-Factor”. The X-Factor is the difference between what the consultant initially bids to win the contract, and what is ultimately delivered to the client. It is sometimes referred to as “low ball pricing.” These terms accurately reflect the standard practice of bidding on the project as defined. However, “there is conscious intent to solicit, promote, and champion requirements changes.” 

Standish Group continues: “The X-Factor will alter the ultimate deliverable from the project as initially defined and increase the cost. The X-Factor cost increase can occur through requirements analysis and validation. At the end of the process, the unselfish consultant provides recommendations for changes and/or additional requirements based upon user input and their own analysis, demonstrating that the project as originally defined and presented will not meet the business needs, which is something they knew all along. 

“The X-Factor final deliverable is not necessarily better. It might be worse. It is guaranteed to be different. Since requirements changes represent more money, the consultant will encourage changes at every opportunity. The end result of it being more billable hours for the consultant. The X-Factor and the other twenty factors message here is caveat emptor or let the buyer beware.

“On the surface, the X-Factor and the other twenty factors could be casually dismissed as justifiable and acceptable risks of doing business. In reality, they are carefully devised and skillfully practiced techniques designed to serve the primary objective of the consultant to maximize their profit.

“The addition of complexity and confusion is the common denominator. This gets manipulated into project expansion, schedule delays, requirements changes and additions, new hardware, new applications, system integration projects, and a “till death do we part” relationship. The consultant’s hooks are in so deep that the cost of terminating the relationship is unaffordable. The consultant will pretend to be a trusted and friendly advisor until the profit well runs dry.

“When a conflict occurs between the client’s interest and the consultant’s profit, the consultant will protect his profit. “Show Me the Money” was the mantra of the consulting world long before it became a signature line in a Hollywood movie. This mercenary depiction of consultants is not an individual or personal indictment. It reflects the nature of the industry. The behaviour pattern and mode of operation is a reaction to the “survival of the fittest” environment.

“Consultants are under enormous pressure to develop the business; and they face intense competition. This breeds their overly aggressive, relentless pursuit of the bottom line. The consultant is neither friend nor enemy; he’s an entrepreneur in business to make a profit.”

Admittedly, this X-Factor scenario will already be familiar to many companies in their dealings with consultants. Over the coming months, Standish says it plans to take a closer look at some of the other key factors to be aware of around using consultants.

Chaos Activity Newsletter

Standish Group: the role of the executive sponsor in IT projects

By David Bicknell

The US-based Standish Group has published a series of excellent pieces on its blog over the last few days over the role of the executive sponsor in IT projects.

The blog features an interview with Eugene Bounds, senior vice-president at Booz Allen Hamilton.

Bounds says, “I was first reached by the then current executive sponsor of a project called “RightIT.”  RightIT helps organisations optimise their IT investments.  The project combined the capabilities of IT, PM and cost.  He had the expertise in IT and he wanted my expertise in programme management and finance.  I eventually became the executive sponsor for the RightITTM project. 

“The first thing I did was to establish frequent and standard meetings; so, every Friday we had a team meeting.  My commitment is to be available for guidance and status reviews.”

Bounds adds, “As executive sponsor of the RightIT project, I thought it was critical to understand who on the leadership team would be affected or could gain benefit from the RightIT project.  I then reached out to these colleagues to establish an advisory group. 

“As part of the advisory group, I established monthly meetings.  This gave me an opportunity to get direct stakeholder feedback and support.  If we were producing an artifact, I wanted their thoughts on it to make it better.  I wanted to make it packaged and ready to go.  Of all the things I did as an executive sponsor, this was the most important.”

“The problem is that project managers have their own view and language.  The project manager looks at the project tactically.  He or she looks more in the weeds of the project or the details to try to get it done.  The executive sponsor tends to look at it as a strategic event.  He or she will look at the project on how it aligns with the goals of the organisation. 

“In the project management profession we have our own language and plenty of acronyms.  So there is a gap and it really is up to the project manager to fill the gap.  We cannot expect the executive sponsor to understand the PMBOK (project management body of knowledge) and all of its artifacts and processes.  It is up to the project manager to make that translation.  Executive sponsors on the other hand have the responsibility to ensure that the project manager makes that translation.”

The Standish Group points out that the executive sponsor is “the owner of the project. As the owner of the project, the full weight and responsibilities of the success or failure of the project falls squarely on his or her shoulders. The executive sponsor, for better or worse, owns the outcome. The executive sponsor has no right to abdicate his or her executive responsibility. He or she cannot blame the project manager, the IT executives, users, stakeholders, reluctant peers, vendors, or software developers.

“The sole responsibility for a successful outcome rests on the shoulders of the executive sponsor.  The sponsor may not be an executive of the organisation, but he or she is the chief executive of the project. The word ‘executive’ symbolises a higher level of responsibility. It is more powerful than just ‘sponsor.'”

Why prompt decision-making is critical to the success of IT projects

By David Bicknell

Research from the US-based IT projects specialist Standish Group suggests latency between decisions is a major contributor to project delays and failures.

“Projects get behind a day at a time. My observation is they get behind because people cannot make decisions. Therefore, it is important to establish a process that enables you to quickly gain the decision information you need,” says Mike Sledge, chief executive of corporate performance company Robbins-Gioia.

There are literally thousands of decisions that have to be made during the life of a project. Standish Group research shows that for every $1,000 in project cost, the organisation will need to make 1.5 decisions. A $1 million project will produce 1,500 decisions, while a $5 million project will have 7,500 decisions. During a typical medium-size ERP system implementation the organisation will have to make more than 10,000 decisions.

“The key reason for making fast decisions has nothing to do with always making right decisions. It has everything to do with being open to mistakes,” says Richard Mark Soley, chairman and CEO of the Object Management Group (OMG). 

Standish Group took the case of two US companies in the same sector that were both implementing customer relationship management (CRM) systems. Both companies were similar in size, number of accounts, and salespeople. They even used the same software package.

Both started to implement a CRM system about four years ago. One finished in six months and the other has still not finished. The key difference was the one that finished in six months had a hard stop and had set up a rapid decision process to reduce decision latency.

Standish Group goes on to say that while the volume of decisions comprising a project can be a problem, it is actually the time that lapses from when an issue first arises until a decision is made that causes most difficulties.

For example, if the average decision latency is only one-hour, then the added decision time to a $1 million project is six months (1,500 decisions = 1,500 hours). On the other hand, if the project team can cut the latency time in half, it adds only three months to the project time (1,500 decisions = 750 hours).

With this insight into the corrosive effect of slow decision-making on project success, and after years of research in project management performance, the Standish Group decided to develop The Dezider, a real-time information decision support solution to help organisations cut decision-making time in half through greater stakeholder participation and more information.

The intention behind The Dezider is to connect individuals with their co-workers, stakeholders, peers, superiors, friends, and family as an aid to decision-making.

One way to increase decision velocity, decrease latency, and increase people’s participation is to simplify large issues by breaking them into smaller issues and decisions. (You may recognise something of an Agile-like approach to decision-making here)

The Dezider enables the ability to create a series of minor or micro issues and to construct a stream of responses to achieve quicker, easier, and more comprehensive answers. Each of these micro issues can then be directed to the proper level, role, and/or responsible person(s).

What usually happens in organisations is that people are busy doing their main jobs and often put off project tasks such as participating in project decisions. The Dezider offers a feature that gently reminds project participants that they have an outstanding issue and the team is waiting for their response.

Another feature within Dezider provides the ability to match the type of decision with the roles of the people making the decisions. For example, a technical decision should have a technical person making the decision. On the other hand, a business decision should have a business person making the decision.

There are more details about the impact of decision-making on projects, and about The Dezider on the Standish Group blog. Standish Group is probably best known for its Chaos research into project management leadership and best practices.