Explaining “Speed vs. Thoroughness” trade-offs

I was asked recently about how to balance quick delivery vs. complete (or enough) scope.  Unfortunately, my initial answer sounded lame even as I was explaining it… I later remembered a better example of how to aim for “quick-but-real” wins while planning and executing broader and deeper solutions to the issues at hand.

Such trade-offs are, of course, the life-blood of managing initiatives.  And, of course, one may will have to spend a bit more in resources to get speed and thoroughness (that pesky triple constraint… here and here).  But there’s also the risk management angle to consider.

In particular, the ability to deliver on both “fast” and “thorough” tracks is essential in organizational or business change projects.  Properly targeted and communicate “quick-but-real” deliverables are excellent responses to the risk of poor or no acceptance by stakeholders.  This approach is a way of buying cheap insurance (I know, I know…insurance is a different response type technically) against much bigger risk impacts down the road.


Perils of being a “brand protector”

I’m sure you all have seen the bad publicity SAP Services got via a news story on Bloomberg about the Shane Company bankruptcy filing.  Josh Greenbaum picked apart the piece pretty comprehensively (here) and the Shane Company itself came out with provided a statement that SAP can use to clear the air (NOTE: struck out section reworded in bold to clarify):

Press coverage resulting from the Shane Company Chapter 11 bankruptcy filing has unfairly characterized SAP as the cause of Shane Company’s cost overruns based on the software applications licensed from SAP in 2005. Project implementation cost overruns were caused by a failed implementation process utilizing multiple third-party industry experts.  After not meeting expectations, the Shane Company contracted SAP Services to restart the project which they played a key role in implementing, stabilizing, and further enhancing the system.  In fact, we have a strong business relationship with SAP and will continue working with them as we emerge from our Chapter 11 bankruptcy filing.

It is a different consulting business when you’re the services arm of a product company, especially one with a prominent brand.  SAP Services must be vigilant to ensure that our brand value protection efforts aren’t in vain.  It is tough enough to get projects back on track without then seeing stories that suggest we weren’t effective.

PM Quote of the Day — Vince Lombardi

Practice does not make perfect. Only perfect practice makes perfect.

When I was younger, I never got the point of practice.  Sure, I knew that it would get me in shape and knock of the rust off.  However, I never got the idea that practice would help me perform better under pressure.  Too many times I found myself over-thinking a situation because I hadn’t practiced enough to make it automatic.  I finally started to realize that realistic practice in all sorts of endeavors — in particular, public speaking and presenting — helped to take the edge off along with the rust.

Practice?...  Youre talkin about practice?

Practice?... We're talkin' about practice?

Lombardi’s point also applies to how we test our processes and systems.  Too often I’ve seen customers and consultants assume away difficulties in their desire to save testing time and money.  Even worse, this saving “spasm” usually comes towards the end of the project, just as the testing was about to get serious.

The best testing practice (so to speak) I’ve seen came at a global firm that does dirty and dangerous work.  As you might imagine, that company is very conscious of safety and quality.  That firm called their last round of testing not integration or user acceptance, but “business simulation.”  Business simulation didn’t simply involve folks following a script.  We brought the system, interfaces, and data up like go-live, then encouraged the users to go “do their jobs” and call support if something went wrong.

Sure, such an approach is expensive.  But how much is that peace of mind that comes with a no-holds-barred validation that the system and its support conformed to requirements worth?

Corner Cutting Survey Results: Risk Monitoring

The corner cutting poll’s third answer (at a low 12 percent) is “On-going risk monitoring and control”.  That result was quite a surprise to me.  Neglecting to perform risk activities beyond initial identification and analysis is one of the most common project mistakes that we see.  Surprise at when risks become issues — or when they become so likely to happen that they should be managed as issues — is a consistent marker of troubled projects.

In our experience, we get a great start in risk management and start our projects with an excellent list of risk events.  Furthermore, we usually will have done good quantitative and qualitative analyses, though appropriate risk response planning is less systematic (which is why it was a poll question).

Any ideas why this came in so low?  Maybe it’s just that Crossderry readers are very sharp and would never miss something so critical :-)   That shameless pandering aside, I’m wondering whether this result was driven by some characteristics of the poll:

  • Was it clear that multiple answers could have been given?
  • Did respondents understand the implied distinctions drawn among the various risk management processes?
  • Was the answer worded well?
  • Was there another risk-related answer that would have worked better?

Corner Cutting Survey Top Answer: Not communicating with senior management

Executive body language after cancelling too many meetings

The corner cutting poll’s top answer (at 22 percent) remains Executing planned communications with senior management.  This answer matches our own experience within SAP, which indicates that proper stakeholder management decreases the probability of risk events, shortens their duration, and lessens their total impact. 

In our experience, the most frequent communications mistake was failure to execute planned executive-level messaging, which eroded the project manager’s position in the eyes of sponsors and other leaders.  Such an erosion of a project manager’s position leads to negative second-order effects, including:

  • Mistrust of the PM’s ability to lead and prioritize.
  • Senior management bypassing the PM in favor of direct communication with team leads and vice versa.
  • Exclusion from decision-making bodies or meetings.

PM Corner-Cutting Poll Results — as of 25 Sept

I had 46 49 (51 now) responses to the my survey question “What are the most common areas that are “cut” in projects or programs?” Below is a bar graph with the current results (I’ll keep the poll open for a while on the right-hand sidebar of Crossderry).

In future posts, I’ll have some commentary on the “top” answers.

Don’t forget the “corner cutting” poll

I’m getting some good response to the “corner cutting poll” on the right sidebar of the blog itself, but I’ll leave it open for a while longer. 

For my newsreader subscribers, the poll’s direct URL is here: http://www.polldaddy.com/p/775626/

Structuring Risk Statements

Rich Maltzman at Scope crêpe has a post that highlights the need to appropriately structure risk statements (here).  I had commented (here) on Rich’s earlier post (here) on assumptions and risk.

A common feature of troubled projects is that their risk statements (if they exist) are too generic.  In other words, they could apply to any project, with any deliverables, at any time.  Rich ID’s what drives this mistake — at least, IMHO:

Well, when you as a project manager are assessing your risks, you need to ask – repeatedly – how each risk could add to (as in opportunity) or take away from (as in threat), your project objectives. Sometimes PMs start their risk assessments before they really know what those objectives all are….

He also passes along some practical advice on structuring the statements themselves (from David Hillson and Peter Simon’s, “Practical Project Risk Management“):

Risk Statements are highly-structured sentences, with an “if-then” flavor, which convey clearly what the risk at hand is all about. Each risk statement should include a Definite Cause, an Uncertain Event, and an effect on a Project Objective.

Too many PMs “fight the last war” or lean heavily on “best practice,” so their instinct may lead them to the ol’ copy-and-paste method of risk ID.  Using a risk or project review to subject risk statements to the “if/then” test will encourage PMs to focus on actionable risk events (rather than catch-all CYA risks).

Read Rick’s post for more specifics…

Reducing SAP implementation time/cost

A case study (here) and press release (here) about a quick, clean SAP Business All-In-One implementation at TomoTherapy.  What stands out about what worked?

  • Using SAP Best Practices as the baseline.  It makes it very easy when one can leverage a fully documented and functional prototype.
  • Using a partner willing to leverage SAP Best Practices.  It is instructive that two partners wanted to build from the ground up.  itelligence is an SAP Best Practices partner (see list here) — the case study is a little misleading about their role in SAP Best Practices — so they were able to bring speed to the table.
  • Splitting the Blueprint SOW from Execution SOW.  We are doing more and more T&M design SOWs, which is great way to get “everything on the table,” as TomoTherapy’s IT director stated.

An aside: it is funny to see that while implementation took only 16 weeks, but it took the PR machine 14 months to get out the word.


Legal vetting helps reduce project failure

Interesting SearchCIO article on leveraging legal (and purchasing) expertise to faciliate deals (here, I think this is available w/out the free registration).  A few comments on the speech by Erik Phelps:

“It is not just the ‘bad vendor’ who sells the software; often it is the bad customer who isn’t going about the procurement process very well,” …. [c]hanging how the deal goes down, he argued, improves the acquisition process and minimizes the project’s risk of failure.

We get worried when we see a customer that doesn’t appear to have any “checks and balances” on the procurement process.  If we aren’t getting asked hard questions, then are we being set up for failure?

The first step in improving the acquisition process is to know the kind of deal you want before you start, Phelps said. Not surprisingly, he recommends that CIOs get their lawyers in the game early.  By the time lawyers are usually called in, it’s too late.

Oh, yeah.  If lawyers come in late, everyone will want to lawyer up.  Read the whole article for more good stuff — encouraging vendor input to speed RFPs, make vendors accountable for RFP answers, allow vendors to propose changes to contract terms.

%d bloggers like this: