Wednesday, December 29, 2010

Defining Business Requirements

In my recent blog about consultants, I highlighted the work of Robert X. Cringely, who noted that most IT projects fail at the requirements stage.   This is topic worth its own blog post.

In my roles at various institutions, I've had the opportunity to work with thousands of highly diverse stakeholders.   Some are IT savvy, some are not.   Some are project management savvy, some are not.  Some understand leading practices for their particular departmental functions, some do not.

Here's what I've learned.

1.  Automating a dysfunctional manual process will not yield a successful performance improvement outcome.   Before any technology project is launched, the business owners need to understand their own process flows and goals for improving them.

2.  If business owners cannot define their future state workflows, software is not going to do it for them.   Sometimes, business owners tell me "I need to buy a wonderful niche software package from XYZ vendor."  When I ask how they will use it, they answer that the software will define their workflow for them.

3.  The IT department can impose governance and project management processes to ensure that future state workflows and requirements are defined prior to any procurement processes.  However, the business owners who are least experienced with project management methodology will accuse the IT department of slowing down the purchase.   One way around this is to create an institutional project management office outside of the IT department which serves as a bridge between the business owners and the IT organization providing the service.  Such an approach adds expert resources to the department requesting automation to lead them through a requirements definition process as a first step.  Projects without clear requirements and goals can be stopped before they expend time and money on an implementation that is likely to fail.

4.  Some departments will try to circumvent governance prioritization and project management processes by contributing departmental funds, obtaining a grant, or getting a donor to fund their software purchases.   Such as approach should not be allowed for many reasons.  Software licensing is generally about 20% of total implementation cost which includes hardware, configuration, interfacing, testing, training, and support costs.    Every software implementation is a project and needs to be considered a use of scarce IT resources.   It is reasonable to initiate an automation request through a project management office to define business requirements and goals, then present it to a governance process for prioritization, then fund the total project costs via departmental/grant/donor dollars if the project is deemed a high priority for implementation.

5.  Creating formal documentation of business requirements, goals/success metrics, and forecasted financial impact is important to establish ownership of the project by the sponsoring department.   Although infrastructure projects such as provisioning networks, desktops, storage, and servers can be owned by the IT department, application projects should never be owned or sponsored by the IT department.   The business owner, working with the institutional project management office, needs to drive the implementation to achieve the desired process improvement and to ensure appropriate change management.   If the project is considered an IT effort, then business owners will claim their lack of requirements definition or process redesign is an IT failure based on poorly designed or implemented software.

Thus, however unpopular it makes the CIO, insist on business owner sponsorship with defined requirements, goals, and accountability for process and people change management.     Every project I've been involved in that includes this role for the business owner has been successful.  With clearly defined responsibilities and accountability, customer satisfaction with these projects has been high, because business owners feel compelled to make the project a success rather than expect IT to deliver a finished project to them.

9 comments:

Arthur said...

Has BIDMC implemented a PMO outside of IT? If yes, what are the rules of engagement with IT?

Michael said...

I write a blog for ZDNet called IT Project Failures. Would you be interested in putting together a guest post on this important topic?

Here is a link: http://www.zdnet.com/blog/projectfailures

Jeff said...

I'm pleased (but quite shocked) to see a CIO actually say what you've proposed here. Having been the "licensing and contracts guy" on tens of thousands of deals, I have tried on numerous occasion to slow a bad deal in an attempt to solve some of the issues you discuss.

In most cases, however, it's IT management that is feeling pressure from above and passes it along to the PMO... who then signs a deal that they believe will yield success simply because it's software.

Today, I spend the bulk of my days trying to extricate organizations from bad deals. Quite frankly, it's a lot easier if they simply wouldn't get inked in the first place.

Tony K said...

As is too often the case, the overriding management attitude is "There is never time to do it right, but there is always time to do it over."

geekgoalie said...

Strong corporate governance is a powerful tool that can be used to keep from starting projects that have little or no chance of success. In your case, it may be easier to enforce since the CIO is also an MD, and doctors are more likely to respect the advice of another MD than they are advice from non-md IT professionals.

rvaughnMD said...

Excellent summary of required steps for success. Many (both on the customer and IT side) do not want to take the time to map their very complex processes. EHR cannot achieve the proposed outcomes without clinical leaders leading change. Sometimes all we can offer is a report of outliers for clinical processes for clinical leaders to manage clinicians - but unfortunately they are not empowered nor inclined to do so.

rhorst said...

In follow up to Arthur's questions, what department would the PMO fall under if not IT? Who do they report to? I think it makes a lot of sense, but I think the concept of a PMO is often coming from the CIO, so having it reside somewhere else makes it seem like it would run into issues gaining traction. Great post!

John Halamka said...

In our case, who placed the PMO under the SVP of Capital Projects and Facilities - the person who runs the major construction projects for the organization. In a former job, our SVP of Capital Projects built Deer Island, a multi-billion dollar technology project to clean up Boston Harbor.

Michael said...

I wrote a post riffing this one, called "CIO view: Business requirements and the elegant art of 'no:'

http://www.zdnet.com/blog/projectfailures/cio-view-business-requirements-and-the-elegant-art-of-no/11949