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.
No comments:
Post a Comment