Friday, May 29, 2009

Defining the Project’s Scope and Requirements

The Strategy and Planning for the IT Transformation effort must emanate from the definition of scope and the understanding of the requirements that will be targeted by the initiative. Many compromises must be made in the process, and these compromises become both cause and effect of the ultimate strategic direction.

The compromises deal with the interplay of these parameters for each requirement:

§ Quality: The solidity of the deliverable

§ Cost: The amount of money available for delivery

§ Schedule: The expected delivery timelines

§ Scope: The functionality that is being delivered

These variables are known as QCSS attributes, taken from the initials of each. The business requirements can only reasonably specify three of these factors. The fourth factor will be a result of the project’s dynamics. For example, if the business wants a project done within certain cost restraints, under a specific timeline, and with a specific scope, the quality of the project will be in question.

In this diagram, Functionality is represented by the surface area of the square. The Cost used to meet the Functionality is shown in light grey, and the Schedule (timeline) is in dark grey. Quality is the percentage of the Functionality surface that is being covered by the Cost and Schedule squares. The diagram shows that if the Functionality scope is increased (larger surface), you will either have to increase the Cost, the Schedule, or both to match the new requirements; if not, Quality will suffer.

This “law” applies to all projects and to any combination of attributes. Furthermore, imagine the QCSS variables as knobs on a control panel, each influencing the other[1]. The more money available for a given project, the more potential resources that can be committed; thereby enabling faster delivery and/or more extended functionality. With less funding, chances are the scope will need to be reduced if timelines are to be maintained.

Managing the project budget and the timelines is a straightforward project management function. Project Management disciplines to effectively do this have been developed and can be applied in a systemic way. But truth be said, the most complicated challenge during this stage is to properly manage the amount of requirements you are likely to receive from the business. Let’s face it, this is an IT Transformation project that, most likely, has been sold as the mother-of-all-solutions and that will, no doubt, have the business salivating like a kid in a candy store with all the potential for functions that they have for so many years been deprived of.

However, the fact is that the requirements values tend to follow Pareto’s 80-20 rule. That is, typically 20% of the requirements represent 80% of the solution value, and the other 80% the remaining 20%. Now please don’t go to the business and tell then you will cover 20% of their requirements. Not a good idea. First, the Pareto principle is just that—a principle; not a law. It might be that in your case 40% of your requirements represent 70% of the value. Secondly, that little extra business value that can be attained by covering a few additional requirements might mean the difference between having a highly competitive solution or an also-ran.

What you first need to do is identify the 20% to 40% of the requirements that everyone agrees are a must, and then proceed to carefully analyze and prioritize the remaining requirements in light of their diminishing returns. My own philosophy is to do as much as possible with the money and time allocated (in essence, establish first the cost and schedule surfaces) and then draw a line in terms of what requirements are to be met during that first phase. You can place the unfulfilled requirements in a subsequent phase that might or might not be funded on its merits. If you can do so without eliciting the wrath of the business team, then you have succeeded!

As you can see, managing the overall scope is an activity best handled by the project leader and not to be delegated to line project managers. It requires finesse and political skills in dealing with business customers.

A second dimension that is often left unexamined during the requirements phase is the need to assess the project complexity and define the strategy of how this complexity will be managed. By this, I mean the determination of the strategy balancing the target automation complexity versus the reliance on manual processes. This is the subject of my next blog.

Till then.

[1] Microsoft article “A short course in project management” in also has an excellent explanation of the QCSS concept

Saturday, May 23, 2009

Assessing Your Organization’s View of Technology

Some people view their automobile merely as a utility—a means of transportation to get them safely from point A to point B. Others view it as a strategic enabler: “This Porsche is sure to get me more dates!” A corporations’ view of technology is no different. The trick is to find out whether your company views IT as a dependable truck or a sports car.

First, let’s agree there are two types of information system technologies: those needed to support the running of your business, and those that are core to the business. The former include applications such as accounting and payroll systems as well as Intranets. Indeed, the patterns associated with these services have made it easier for major vendors to offer customizable packages under the umbrella of ERP (Enterprise Resource Planning) that can be configured to meet a company’s specific business needs. The latter usually consists of applications and systems formed under more proprietary circumstances and that support the actual business operations: point of sale, promotions, customer relationship management, guest facing sales and marketing (including Web portals and campaign management), product distribution and tracking, reservation systems (such as those used by airlines and hotels), etc.

In principle, ERP systems are needed by all industries, but transformational projects for back office systems can only be truly justified when there’s a need to respond to a big business event such as a merger or an acquisition. Also, ERP investments are rarely justifiable on the basis of competitive advantage—argumentations for cost saving or administrative agility advantages notwithstanding. Instead, large ERP projects are usually approved because they tend to serve the operational governance of the CFO, who ultimately is the person with the budgetary approval power.

Justifying technology transformation projects intended to deliver a direct business benefit is another matter. Their value is often not appreciated because of the high costs. Ironically, because ERP projects typically require proprietary vendor architectures and high-consulting support to customize the solution, they often end up costing much more than IT projects intended to directly deliver competitive features. That’s why there’s always a question as of how to position these core projects in light of the company’s view of technology as a competitive weapon.

Given that IT systems designed to support the core business usually require some costly proprietary development, it has long been a chimera of some businesses to make their core support systems behave the way ERP is viewed today—as a commodity. This view reveals technology as not being a strategic asset, but a utility that’s needed to “get-the-work-done”. Basically, this view of IT is akin to the way most of us view sewage services or electricity—stuff we can’t live without, but that we always expect to work.

Organizations that view IT technology needed for the core business as if it were just a utility are also typically the same organizations whose culture is not predisposed to change. You’ll recognize them when you hear statements such as, “Sure, the business could use this new function but we don’t want to bother with changing things when we can just patch a quick solution for now,” or: “Yes, this new technology will solve many issues, but we can save money by hanging on to we have for a little longer,” or my favorite, overhead from a particularly out-of-touch CEO in the midst of the dot-com explosion of the late nineties: “Nah, if it grows like a weed, it must be a weed. This Internet thing is nothing but a fad!”

Let’s face it. To the executives with that limited perspective, IT is just the geeky intern that shows up whenever there’s a need to “fix” the laptop or “get email going”. This is a view predicated on a strict utilitarian view of IT as a service organization, and nothing more. In this case, your first challenge is to educate the executive brass about the true extent and governance of the IT organization. However, even with all the education in the world, if your company is in an industry that traditionally does not rely on, or get obvious benefits from modern technology, chances are that your attempt to justify that big transformation project is going to fall on deaf ears unless you position your message in line with the company’s culture.

Then there are those companies that consider technology to be a strategic asset . . . Sometimes far too strategic. Frankly, these companies may also suffer from an equally insidious problem of overusing technology. They cling to the belief that technology and only technology will pull the company out of the ditch and increase profitability. I would suggest that a large percentage of the failed IT projects that provided fodder for the Harvard Review’s case studies come from extremely high expectations as to what the ROI mega-technology projects were expected to deliver.

So, there you have it. Understanding the view of technology within your company and your industry is a good starting point in the understanding of the feasibility, scope, and value of your IT transformation effort. What are the considerations for assessing your company’s positioning vis-à-vis technology?

In the diagram above, I give a general assessment of how various well-know companies might value technology. (Note: my sample assessment is completely conceptual, and you have every right to disagree on the manner in which I’ve positioned some of these companies.. More importantly, I suggest you do the exercise of placing your own company in the diagram. The vertical axis represents the typical level of IT investment in relation to the company’s revenue (companies the view technology as a tactical enabler usually allocate 2-5% of their gross revenue to IT; companies that view technology as a core component invest more on it) , while the horizontal axis shows the real or self-perceived value of technology by the company. For example, a company that views itself as one whose actual product is technology related but has a low percentage of investment in IT would fall in the under-investment zone in the bottom right. Your case for transformation should be easier in this case. The upper-left shows technology over-investments. GM (who is o the verge of bankruptcy as I write this) was typically a heavy investor in technology, even though it did not traditionally position itself as a technology company, but rather as a car company—a big car company (Hummer or Yukon, anyone?). In fact, EDS was spun off from GM after some executive concluded that providing DP services was not a business GM should be in.

The two sample brands to the left are representative companies that might well see technology as a utility. They do depend on technology, mind you, but chances are they want it as cheaply as possible, so they can focus on their actual lines of business: selling food products. Some companies see technology only as a tactical enabler. Here I’m thinking of manufacturing and retail that tend to view technology as something better than a utility but still not core to their business. Still, just because a company requires technology only as a tactical enabler does not mean that IT can’t be leveraged against the competition. Even in this scenario there might be IT contributions to the core business (e.g. automated ordering kiosks in retail, use of loyalty systems and CRM.)

In the middle of the horizontal axis, there lies the Twilight Zone of technology funding. Technology becomes truly strategic when the end product would not exist if technology did not operate with excellence and efficiency. In this area you’ll find companies that have typically leveraged the power of technology to their competitive advantage. Two examples are Sabre, with its powerful computer reservations environments for the airlines, and the financial institution, Merrill Lynch[1], leveraging on-line financial services.

To the upper right of the chart are those companies whose life blood depends on maintaining a leading hand in technology. Further to the right you can find companies whose technology is the actual product. Even though in these companies it might be easier to make the case for technology, don’t be surprised if you get push-back resulting from stale thinking or stunted vision. “Why should we invest in that Internet thing?” someone at Novell might have asked back in the late eighties or, “Why do we need those PCs?” from DEC’s Olsen. Still, there can be no question that the further to the right you find a company, the easier it should be to make a case for technology transformation, if needed. However, in this scenario the execution of technology transformation can be the hardest because in doing so, you are dealing with the lifeblood of the business!

[1] As I write this, Merrill Lynch was just saved from bankruptcy as a result of the 2008 financial meltdown thanks to its acquisition by Bank of America. I left it in this example just to remind us how business events can and do trump any other consideration.