The following is an all too often scenario when trying to implement the enterprise system:
The decision is made at the executive level to build a new computer/software system. A project manager/coordinator is assigned and holds meetings with a newly created RFP committee, stakeholders and users to best determine how this system needs to look, and documents it to tremendous detail. The committee publishes the RFP and invites prospective vendors to submit bids.
After a fairly short period of time, vendors respond, and based on these bids, a short list of potential vendors is created and they are invited to demonstrate their products/prototypes, using both vendor resources as well as the public sector resources. The RFP committee, after another short period of time, makes a final selection and then the contract is negotiated.
The project kickoff occurs; the vendor spends several months or even years developing the system, and a team at the public sector agency helps verify that the system is delivered according to the specifications contained in the RFP. Certain pieces of the system may get rolled out to test users at this point too. During this process, holes in the original RFP are found, or perhaps legislation occurs that must be accounted for. Change orders are submitted, timelines get stretched, and the system costs at least twice as much as the bid.
Finally, the go live date occurs. There is much fanfare, training is done, and users start using the system. The complaints start. Certain influential users seem to sabotage the system. Other users and stakeholders may point out that the system, though delivered as documented, just isn't going to work. When working with the vendor, the change orders will continue to break the budget, and now that the system is in production, these changes cost even more. The downward spiral has begun and there's no saving the project.
Ironically, this is the case in most enterprise level systems. By using best practices, all involved in the project have properly covered themselves, and many have traveled this road before. They approach the entire project assuming it will eventually fail, but make sure they are not the reason for that failure. Proper documentation is in place and no one individual can be targeted as the point of failure.
Why is this so difficult? After all, within individual departments on small projects, there has been much success even with bumps in the road. Issues seem to get addressed and the projects don't get off track much.
There is no simple key cause as to why enterprise projects like this fail. But they can succeed. And it depends on several key factors, each of which must be addressed. One weak link can destroy the project.
1. The right executive has to oversee the project
This doesn't mean the executive has to manage the project. Many times responsibility for a project may fall on a single department, yet other parallel departments are part of the project. This is a recipe for failure. The executive must be high enough in the hierarchy to be in charge of ALL departments involved, and must oversee and provide "air cover" for the project. As an example, let's assume a new juvenile justice case management system is to be implemented. Within the juvenile justice agency are several departments. Let's assume (in a very simplistic way) that there is an IT department, a department that oversees private providers, a department that oversees the public agencies, and a department that oversees administration and regulations. Often times, the IT department will naturally be given the authority and responsibility to implement the new system. WRONG! In this case, the Juvenile Justice Agency head (or even higher level) must be actively involved and ultimately oversee the project. Only this executive can resolve issues that may occur between the other departments. This executive must be absolutely committed to the project, and that means this executive must be involved in all stages of the project, from RFP to vendor selection to final rollout.
2. The right project manager and methodology have to be selected
A project manager who is a stickler for detail and follows rules including all project management best practices may sound like the right fit. However, this is not the case, especially in more complex implementations.
The project manager needs to be experienced not only technically, but also politically. This is a special person that performs multiple roles: Documentation, budgeting, cheerleading, diplomacy, as well as many other hats. This person is absolutely full time during the project and becomes the key person who can be contacted about anything regarding the project. This person works directly for the key executive and they have a relationship that is strong enough to carry through some of the project lows.
This person must be able to deal with adversity and also be able to take responsibility during bumps in the road. This person must have the right attitude. If a problem occurs, this person must be more concerned with the solution than deflecting blame or covering themselves. Because this person has the right relationship with the key executive, they will not have to worry that every decision made during the project is perfect, only that if a decision isn't right, they have the ability to perform corrective action.
This person also needs to be able to manage a project using an iterative process. As described above, no matter how carefully thought through and documented new requirements will come up that weren't thought of, or legislative/rules changes may occur during the project. This should carefully be brought up so that those involved in the project won't worry that every possible detail is locked in stone until the product is delivered. If project participants believe there will be no accommodations for change, then they will try to design something so complex as to handle every possible anticipated scenario, and the system will end up cumbersome and difficult to use.
3. Change Management must start before the RFP is even published
Enterprise projects mean change. For most people, this is stressful. After all, they are used to their processes, know the glitches and work-arounds in their existing systems, and think the pain of a new system just isn't worth it for them. Often times, the new system will replace a "perfectly good" system they are using, and in many cases, people will actually lose some of their power due to more availability of information that they used to have in their control. Naturally they are resistant to change.
Of course change management strategies must be used especially in enterprise level projects. But they need to be started right at the earliest stages of a project because small problems at the very beginning with key people can destroy enthusiasm and goodwill of key players.
A good way to keep all abreast is an active internal website where content regarding the project is continually updated. It might be good to consider a web log and accept user feedback. A very new trend in the high tech world is the CEO/executives of companies actually running a blog and accepting all types of feedback, both good and bad. Sometimes it's the fact someone is being heard that's more important than an action being taken.
As stated in the project management section, early on in the project it is important to allow for some (but not excessive) changes to some of the low level detail design as the project progresses.
In our next article, we will uncover even more powerful reasons to pay close attention to when implementing your system. Stay tuned.... And if you'd like more information regarding this topic and many others regarding custom software development for training, case management, sales and marketing and advanced data analysis, please visit www.globalvisiontech.com.
Copyright © 2006 Chris Freund (All Rights Reserved)
Chris Freund is the President and CTO of Global Vision Technologies, Inc (GVT)., http://www.globalvisiontech.com a premiere software developer specializing in powerful, easy-to-use Internet systems for case management, child welfare, court reimbursement, online training and development, sales and marketing intelligence and pharmaceutical analytical, market research and data capture tools,. GVT's primary goal is to provide our customers with proven technology systems for improving their productivity, profitability and overall business efficiencies. |
No comments:
Post a Comment