Avoid Scope Creep in Enterprise Software Implementation

[fa icon="calendar"] Mon, Sep 13, 2010 / by Tim Lozier

Project Scope Creep - This is one crazy set of requirements!In a few previous posts, I spoke about how important it is to take time to select the right vendor for your software solution. Interestingly enough, while many companies focus heavily on the software's ability to meet the business need, very few focus on the vendor's ability to implement the software.

Sounds crazy - a vendor who can't implement their own solution properly. Well this is half true. The responsibility of a software implementation project is shared between the vendor and the customer. While the vendor needs to deliver on all those promises they made in the RFP, the customer needs to make sure that their processes are well-defined, and that all the requirements of the solution are outlined in detail. Without the roadmap for the solution, the vendor can only take a "best attempt" at meeting the business need. Kind of like shooting a moving target in the dark, blindfolded and with one hand tied behind the back.

With all the investment put into selecting a software vendor for your business, it is hard to believe that there is any possibility of failure. However, recent studies have shown that within a sample set of more than 9,000 software rollouts, 71 percent either failed or were late and over budget. Even more staggering, a recent study by Gartner Research revealed that nearly four in ten major software purchases ended up as "shelfware" - software that was purchased, but never implemented. The root cause of such pitfalls is usually attributed to challenges associated with project management, and the inability to properly define the requirements to make the implementation successful. As a result, the end users never really accept the solution and the cost to implement correctly becomes extended.

Successful projects are the result of the quality of the solution and the acceptance of the solution by the end users. As seen in the diagram below, without proper planning and project definition at the start of the project, implementation projects can often suffer in the long-term. Projects without a defined scope will often require fluctuations in resource levels, and push the project out far beyond its expected completion.

The Project Management ParadigmHere are just some quick points to consider when looking at an implementation project:

Get the Requirements up Front: While this may seem like a no-brainer, many companies won’t truly know what their requirements are when they start a project. You may have one or two project managers who swear up and down they know the processes, and do not need this exercise – until you actually get all the stakeholders in a room. At that point, the picture gets painted a different shade of what you thought. Many times, the stakeholders will “trickle in” during the project after implementation has begun, and this is the source of the evil “Scope Creep” paradox. The more features we want, the more time it will take, the more time it will take, the less likely the vendor is to deliver it on time…on and on we go:

Scope Creep Paradox

By gathering all the stakeholders and by clearing defining the project and its requirements at the start, the actual implementation process will move much smoother. No one is “trickling in” and all elements of the project are planned and ready to go. This early investment of time in the beginning of a project may seem like it would take longer on the outset, but in reality, this up-front investment of time actually speed the project up in the long run. Resources are efficiently managed, project timelines are met, and this project is delivered on time and on budget.

Get a Design Specification: Whether you are implementing a configurable, out of the box solution or a heavily custom developed application, getting a design specification is an important step in the process. A design specification is essentially a simple mock-up, “wire frame” or depiction of what the final product is going to look like once implemented. These are typically done in phases of the implementation, so that each “piece” is given its own design spec. Think of it like building a house. You would want to see the floor plan before they start laying the foundation, and building up the rooms. You want to make sure the bathroom is in the right place, the kitchen, and so forth. Same goes for the software solution – making sure the forms look right, the fields and keywords match your ideas, and are in the right place are very important.

At this point, with the requirements gathered and design specifications in place and approved, then the really implementation can begin. Whether configuration, coding, or paper clips and duct tape, most implementations will vary, but ultimately the goals are similar. This is to deliver the finished product according to the information provided in the first two points. Ensuring the finished product matches your requirements exactly is important, which is covered in the next point.

UAT – User Acceptance Testing: I’ve posted before on the importance of involving the end users in the process – they are after all, the day to day users of the system. Their acceptance of the system will ultimately determine whether the new solution is truly a success or not. The UAT phase of the process is like the “test drive” of the new sports car – making sure that the seats are comfortable, the engine is tuned, and the wheels won’t fall off. Just the same in the software world – move around through the workflows and forms, push the performance, and make sure the proverbial “wheels stay on.” This is usually done by the company’s project team, but many like to take a few of their end users and let them comment on the system. This is a good practice to get the “word on the street” for those daily users.

The theory behind using this project management/requirements first approach to implementation is that during UAT, only minor problems are tweaked. The last thing either party wants is a major technical flaw this late in the game.

Investment in software shouldn’t fall victim to a poor implementation. Not only does it leave a bitter taste in the mouths of the project team, but the software investment becomes diluted and could end up as “shelfware.” Ensuring the project requirements are gathered at the start, the design is approved before implementing and testing on the backend will help to make sure the project is completed within scope and within budget.

Topics: EHS Management Quality Management Build vs. Buy

Tim Lozier

Written by Tim Lozier

Tim is the Manager for Marketing and Strategy at EtQ, Inc.

Post a Comment

Subscribe to the Blog

THE PROACTIVE QUALITY ECONOMY  Join ETQ as we explore the six key pillars to driving sustainable business growth  and integrity