j e s r u s h . c o m

Most day-to-day project or operational decisions don’t require grand meetings and circumstance, but there are some situations where gatherings should be called to make decisions:

• Whenever group input is likely to significantly improve the quality of the decision.
• Whenever the problem is complex and requires multiple specialists.
• Whenever team members might have difficulty accepting a decision

So how does a project manager or leader facilitate these decision-making sessions? I’ll share my basic framework:

1. Identify the problem. Clearly state the fundamental problem and its context. The key thing here is to avoid framing the problem in terms of choices (predefined choices kill creativity). The WRONG way: “Should we abandon the mapping component entirely or substitute an alternative map module?” The RIGHT way: “The mapping component difficulties have put us ten days behind schedule. We need to determine the best way to move forward.”
2. Generate options. Begin by establishing a moratorium on criticism. All ideas–even the craziest ones–are wanted here. Make the point that all ideas belong to the group, nobody “owns” an idea, and everyone is free to twist and extend ideas suggested by someone else. Try to gather as many ideas as possible (quantity over quality) and be sure to prompt/include anyone who is naturally shy or not participating. Put all ideas up on a whiteboard as they come in.
3. Set evaluation criteria. The team needs some way to sort through the options. If you established an expectations management matrix with the sponsor (which prioritized scope, schedule, or budget) or if you defined a project vision (e.g. “Put a man on the moon by 1975″), then you have your basic criteria there. For example, an alternative which pushed you past 1975 would score poorly.



4. Facilitate a Decision. Provide summaries of progress and keep the group on track. Protect minority opinions and ensure that everyone has a say. Test consensus and re-state your understanding of what is being said (silence does not equal agreement!). Some conflict here is acceptable (even desirable), but if tempers flare or it becomes dysfunctional — then end the meeting and reschedule another one.
5. Follow Through. After the decision has been made, the group should later be called together for a miniature ‘lessons learned.’ Did the decision turn out to be the correct (or best) one? If not, what threw the group off? How can a better decision be made next time?

   The bottom line is that if you want good decisions, you must follow a good decision-making-process!

CIO.com has a great new article on a recent survey from Panorama Consulting Group about 670 ERP implementations which Panorama studied.  Among the nuggets:

The majority of respondents (77 percent) had chosen a Tier I provider (SAP 35 percent; Oracle 28 percent; and Microsoft: 14 percent). The rest (23 percent) went with the Tier II.

So, what was the total cost of the average EPR implementation? SAP $16.8 million; Oracle $12.6 million; and Microsoft $2.6 million. Tier II average: $3.5 million. (Microsoft’s figure is pretty impressive.)

And how long did it take respondents to fully implement the ERP solution? SAP 20 months; Oracle 18.6 months; and Microsoft 18 months. Tier II: 17.8 months.

Now, the multimillion-dollar question: How satisfied are the executive team and users with the ERP solution? SAP 73 percent (Panorama’s “satisfaction rating”); Oracle 62 percent; and Microsoft 69 percent. Tier II: 70 percent.

Fascinating stuff, especially the low cost of Tier II ERP implementations (NetSuite, etc.) and of Microsoft!  I expect SaaS ERP to really begin taking off this year.  Now that security concerns have been mostly allayed, the value proposition on turnkey, hosted, no-license-fee ERP is just too good.

A friend in IT recently asked me to explain cloud computing to them. It’s a complicated question because 1) personal cloud computing (think Sugar Sync, etc.) is very different from enterprise cloud computing (think Amazon S3, etc.) and 2) The vendors offering cloud services are offering really different products from each other.

I gave my friend the best summary which I could, but later I referred him to this old but excellent summary of the state of cloud computing. It has great great play-by-play on the offerings from each of the major vendors.

Things have shifted a little bit since then, but this is still the best summary I’ve seen on the web. And Amazon is still kickin’ everyone else’s butt with their simple image-based solution.

I wanted to share a handy little tool which I picked up awhile back: The PIECES framework. This short checklist is simply a list of things to think/worry about when designing, building, or implementing a system or application.

I suppose there are a lot of frameworks and checklists floating around out there, but this one happens to be really good. I use it not only for design, but also for change management to make sure I’m not forgetting anything. I have no idea who created it, but I’m forever in their debt!

Performance
   -Throughput
   -Response Time
Information (and Data)
   -Outputs
      +Lack of any information
      +Lack of necessary information
      +Lack of relevant information
      +Too much information – information overload
      +Information that is not in a useful format
      +Information that is not accurate
      +Information that is difficult to produce
      +Information that is not timely to its subsequent use
   -Inputs
      +Data is not captured
      +Data is not captured in time to be useful
      +Data is not accurately captured – contains errors
      +Data is difficult to capture
      +Data us captured redundantly – same data is captured more than once
      +Too much data is captured
      +Illegal data is captured
   -Stored Data
      +Data is stored redundantly in multiple files and/or databases
      +Stored data is not accurate
      +Data is not secure from accident or vandalism
      +Data is not well organized
      +Data is not flexible – cant meet new info needs from stored data
      +Data is not accessible
Economics
   -Costs
      +Costs are unknown
      +Costs are untraceable
      +Costs are too high
   -Profits
      +New markets can be explored
      +Current marketing can be improved
Control (and Security)
   -Too little security or control
      +Input data is not adequately edited
      +Crimes (e.g. fraud, embezzlement) can be committed against data
      +Ethics are breached: data or info gets to unauthorized people
      +Redundantly stored data is inconsistent in different files or databases
      +Data privacy regulations or guidelines are being (or can be) violated
      +Processing errors are occurring (people, machines, or software)
      +Decision- making errors are occurring
   -Too much control or security
      +Bureaucratic red tape slows the system
      +Controls inconvenience customers or employees
      +Excessive controls cause processing delays
Efficiency
   -People, machines, or computers waste time
      +Data is redundantly input or copied
      +Data is redundantly processed
      +Information is redundantly generated
   -People, machines, or computers waste materials and suppliers
      +Effort required for tasks is excessive
      +Materials required for tasks is excessive
Service
   -The system produces inaccurate results
   -The system produces inconsistent results
   -The system produces unreliable results
   -The system is not easy to learn
   -The system is not easy to use
   -The system is awkward to use
   -The system is inflexible to new or exceptional situations
   -The system is inflexible to change
   -The system is incompatible with other systems
   -The system is not coordinated with other systems

The other day I witnessed a major misstep when a vendor serving my own employer recommended a solution to us which was incompatible with one of our key business constraints.  Fortunately we caught the problem, and the proposal was scraped.

But not everyone is so lucky.  Insane sums are spent on rework for systems which were built with bad or missing information.  As someone who builds and implements these systems myself, I can’t say that there is a foolproof method for uncovering every constraint, assumption, requirement, and interface which might affect the solution I propose.

But I can say that there is a process of due diligence which must be systematically followed to try and fully understand the target business.  I decided to sketch a brief list of things which the project manager, business analyst, and technical lead should look at when building and implementing a solution:

•  Corporate objectives.  The suits might be leery of sharing the three or five year plan with a vendor team, but the more information you can get about the organization’s strengths, weaknesses, opportunities and threats — the better!  Is the organization growing, innovating, changing, and/or trying to cut costs?  If so, how are they accomplishing these things?
• Competitors.  Who competes with this organization?  What does market share look like and how have these competitors designed their systems?  How can they be outdone?
• The Industry.  Checkout the trade journals, attend a conference, and join any industry organizations.  You need to become a kind of insider who can help lead the customer to a solution which they never even considered.
• Org Charts 2.0.  You need to take the plain old org chart and dress it up with some key details for each department or entity: mission, function, and current initiatives.
• Infrastructure Charts.  How do the existing systems communicate with each other?
• Location Models.  Geographically, where does everything sit?  And what laws, cultures, and locale-specific variables change from one location to the next?
• Business Events.  What events drive the business? Do they come from customers, partners, suppliers, regulators?  Who springs into action when these things occur? Do they occur on a regular schedule?
• Process Models.  Workflows and interactions.

While so many customers (and providers) want to dive directly into the requirements gathering phase, there are huge benefits to first researching these domains.  It can mean the difference between a well conceived proposal and an expensive disaster. But more than that, it can lay the foundation for a customer-provider relationship which goes beyond this project.

Imagine if you (as a provider) noticed a trend in your customer’s industry which led you to design a solution for a problem which your customer didn’t even realize they had!

A story: I was once a team member on a project to move an office from one location to another. Even though there wasn’t enough equipment and people to fill all of the available office space in the new location, the project manager insisted on taking advantage of management’s good will and the available resources to build out the unused space.

Several months after the move, employees began complaining about high noise levels. It was determined that the cubicles were too noisy because the ceiling was highly reflective, the cubicle walls were short, and the cubicles were too close together. All of the cubicles office wide—including all of the unused build out—had to be replaced with taller walls and moved farther apart. Fixing the unused build out added about 35% additional cost to the change.

This was a classic case of “overbuilding,” the tendency to buck rolling wave planning and build things now which aren’t needed until much later. You see this all the time in IT Infrastructure projects. A small business learns that a bigger competitor has a high-availability SAN. Because that little business might someday have hundreds or thousands of customers and because they want to “keep up” and look “big,” they spend big money on their own SAN.

Next thing you know, a tiny IT staff has to manage a super-complex system in which they are using 10% of the functionality. Three years later, when better, simpler, faster technology rolls out, they’re stuck with the existing system.

How do you avoid the overbuild mess? By taking the building-block-approach to infrastructure design. A topic for another post…