Ensuring Implementation Success
There are many IT implementation and change management challenges, especially within large organizations. One area that requires special attention is the requirements and analysis portion of the implementation lifecycle. All projects go through a scoping and analysis phase. This is where user and system requirements are identified and documented. Requirements may also be captured during the Request for Proposal (RFP) phase and translated into specific implementation requirements at a later point in time. Regardless of when and where requirements are captured, the evolution of requirements is critical because it drives the development effort. My reference to development encapsulates not only custom software applications, but also includes configuration and/or customization of consumer off the shelf (COTs) packages such as SAP, SalesForce, and EHR applications.
It is estimated that over 68% of projects fail due to inaccurate, or incomplete requirements. The actual cause of these failures is debatable; however, the trend is real. Failure is not driven by inaccurate, or incomplete requirements alone; it’s a lack of understanding and communication that drives up failure rates. Let me give a simple analogy. If I were to ask you to design your dream home in words, what exactly would you write? For example, I would like 4 bedrooms, 3 bathrooms, approximately 3500 sq feet, etc. If I were to give these requirements to a builder to construct my new home, what do you think I would receive in return? Would it meet my expectations? Sure the house would have 4 bedrooms, 3 bathrooms, and 3500 sq feet, but would the rooms be in the right position within the home? Would the ceilings be high enough? Would the bathrooms be exactly where I wanted them located? There’s a high probability that I would want to make changes and as we all know changes are costly and time consuming; therefore, one of the goals is to reduce the probability of changes from ever occurring. In other words, how can I ensure that what I define will actually be built the way I want it?
The reality is that written text alone is a bad way to communicate design, especially for complex systems. I use the word design broadly to mean anything visual that helps tell a story. For example, it can be in the form of process models, screen layouts, navigation, information architecture, and graphics. In the example given above, if I were to have shown the builder a visual representation of the home such as a sketch, blueprint, or 3D rendering; how much closer do you think he would have gotten to building my dream home? The likelihood is high that he would have come much closer to my original vision. Sure there would have been some changes but far less than the text version. It is important to note that most software applications are defined via textual requirements, not visual models. It is also important to note that companies spend a significant portion of their implementation budget on rework. This could be in the form of simple fixes, to full-blown customization changes to existing screens. Lack of understanding in regards to requirements and poor change control procedures contribute to the cost. These issues are the norm, not the exception.
The key point I want to enforce is that in order to effectively manage implementation and change you must find mechanisms to foster better communication about what’s going to be implemented. Visual models should be used to tell a story, build awareness and more importantly, drive stakeholder consensus. For example, my firm uses traditional storyboarding to help solidify our understanding of complex systems. These have proven to be extremely valuable because it removes the technical jargon and puts the focus on the process and users. Since launching software requires people to change their behavior in some way (for better or worse), it’s critical to obtain user buy-in before development and implementation. The earlier you can get users and stakeholders committed, the better. To do this, you must bring them in earlier to the lifecycle prior to making large investments in development. It’s also critical to let them contribute to the vision. This last sentence is essential. The amount of time and energy spent allowing your users to shape the vision directly translates into how successful, or unsuccessful, your implementation will be. To accomplish this, you must employ certain skill sets early in the lifecycle. Such skills as design, rapid prototyping, user experience, and facilitation are all important to capturing and communicating requirements. Open collaboration and knowledge sharing are critical to driving clarity and building a culture of trust and commitment. Companies that do this well stand a far better chance of successfully implementing applications that add real and lasting value to the organization.
