August 01, 2011

Observations in IT Best Practices: Aim Before You Shoot

A few weeks ago I wrote a blog about how some of my best CIO/CTO customers have been asking me how they measure up to their peers in the industry. At that time I wrote one observation was that their IT departments 'played position ball,' or had great role definition. Here's a second observation I've noticed that all of my best customers share:

Observation #2: IT-Optimized Organizations Aim before they Shoot

There are literally dozens of industry analyst reports from Forrester, the CHAOS Group, Gartner Group, and others that document how extremely high the rate of IT project failure is in the United States. Some estimates put the total losses per year at $1-3 billion dollars across industries. One major reason for this failure is how poorly companies document requirements for these projects.

Consider case #1: The RFP. Millions of dollars go into writing RFPs per year. There is a whole industry of consultants out there that write these RFPs, in conjunction with procurement staff and business stakeholders at corporations. And yet those RFPs, which require fixed cost and fixed schedule bids from often-hungry vendors, do little if anything to ensure for an organization that it will get what it is paying for.

An RFP I just received this past week was as good as any to deconstruct. The document called for a delivery date of late September for an enterprise implementation of a Web content management system (needless to say, we no-bid that RFP). The customer had written a great many general questions on what the product could do - questions like "does it have blog functionality?" and "can users post new content to different sections" -- hundreds of very basic questions that pretty much any product vendor could respond to.

What the RFP did NOT do is document a single specific about what the new website should do, the details of how it should work as well as visual depictions (or 'wireframes') to further elaborate on functionality. 

Lets fast-forward to after an RFP has been responded to and the implementation has happened. I regularly get called in on assignment to do a forensic analysis of what went wrong in implementations for RFPs that other tech firms implemented and that DPCI did not win or even bid on. Our policy is to not bid on any RFP that doesn't have good quality requirements. Unfortunately that limits the amount of business we can bid on, but it also helps us keep our sanity by responding only to good quality requirements-based RFPs.

In the majority of cases, those projects failed principally because the functional and nonfunctional requirements were poorly documented, if at all. Thus, the vendor had no specifics to help their customer be successful. Or, still worse, a product was purchased that didn't fit the needs of the customer in the first place. You could blame the vendor, but they were just trying to get gainful employment. The shame is on the issuing corporation, since they could have done better for themselves and their IT partner.

What I have seen with my best customers is that they go through a project chartering process, where staff business analysts work with business stakeholders to articulate business needs and opportunities. Along with these business requirements, the project sponsor from the business side works with the business analyst and a technical resource to define benefits, costs, and risks associated with the initiative. Management then either approves, rejects, or requests clarification on aspects of the charter from the project charter team.

Once a project charter is approved, the project sponsor group then works to define solution requirements in detail. These type of requirements define what the system must do and look like to meet the business's objectives. While parametric estimates have indeed been drawn up as assumptions in the project chartering phase, the project sponsor group further refines and verifies feasibility of functionality with IT liaisons (or a trusted IT consultant) supporting them. Additionally, the project sponsor group works to validate requirements that have been elicited from as broad a spectrum of users as is possible given time and cost constraints.

Thus when we speak of 'aiming' in IT, we talk about a well-defined and repeatable methodology of creating a project charter, getting approval for said charter, eliciting and documenting functional requirements, validating that they conform to the business's needs, then verifying that they are technically feasible.

Sounds like a bit too much overhead? Consider that the best organizations can get this done in a matter of days if not weeks on larger projects. The beauty of the process is that IT and business stakeholders all work together to progressively elaborate the needs of the new system, which is the best possible practice. If both business and IT are in alignment about what a system should do and how it should be built, you have the best results.

There may be a question about who the business or functional analyst reports to within the organization. Some companies have them report into IT, while others see them as resources within the business. For me, I like the notion of IT-as-service-bureau, with the analysts sitting within that part of the organization. The analyst needs to see the business stakeholders as the customer, but must ensure that the quality of functional requirements conforms to the organization's protocols every time.

Some very large organizations see the BA/FA role as rolling into a separate department all together, but I don't see the value of that in most situations. To me, the analyst can play an invaluable role during implementation as well, since he or she can safeguard that the deliverables within an implementation conform to the functional requirements that he/she wrote.

Posted at 12:46 pm by Joseph Bachana

Add comment

• IDEAlliance Webinar on Innovations in Multichannel Publishing 02/08/2012 - 15:01
• On Measuring the Progress of your Digital Asset Management system rollout 02/07/2012 - 13:14
• Drupal 8 Goals Emerging - Interview of Dries Buytaert by Ron Miller 01/21/2012 - 17:29
• Apple iBooks Author and The Walled Content Garden 01/20/2012 - 12:59
• Ten Best Practices in Requirements Analysis 10/06/2011 - 01:55
• Do PMPs make Good IT Project Managers? 08/31/2011 - 13:37
• Observations in IT Best Practices: Involving your Stakeholders 08/30/2011 - 15:43
• Critique of Adweek article by Erin Griffith on "CMS Woes" 08/22/2011 - 23:26
• Article on CMSWire.com about Adobe's Aspirations into Customer Experience Management 08/20/2011 - 00:34
• On Innovation, Research and Development, and Passion 07/29/2011 - 14:59