I am looking for some documentation on the ongoing role and responsibilities of the User and Executive Management following the completion of the implementation of a Corporate Application. This would include activities such as ensuring work practice documentation is in place and relevant, applications are being used efficiently and training for new users.
We are a small global company with approximately 350 employees spread across 14 offices in 5 continents and a consistent methodology is important. Saving Changes...
This may be a little off-topic, but not sure your question is technology specific.
I am having similar challenges in post-implementation of a relatively incremental rollout and, consequently, seeing larger post-implementation issues with a complex initiative that my own firm is about to undertake.
Been reading up on Business Process Management, and what I see as a key early on in the project is getting the business users to become process owners. They have a stake and responsibility in the development, implementation, support and continuous improvement of the processes and the systems that support it. So, when we turn over the system, the expectation is already understood and escalations have already been defined within the organization.
We are not mature by any standard as far as methodologies go. It will be a tough sell for me in the next couple of months to shift and formalize a project organization around that idea. Our users are very "hands off" relative to ownership of technology or the processes revolving around them. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
I find these last two posts to be interesting. One of the key flaws in most MIS organizations is the notion the MIS / IT owns applications and thus acts thusly. This sets up failure after failure as it promotes walls between the real owners, those who benefit from the use of the applications and MIS. What I also find interesting is the notion that the process and method can be evaluated independent of the results achieved. I promise you that the Management and Owners of the business care more about the results than the process. They want good methods because they deliver good results. Therefore the post implementation review must evaluate the process to result relationship. To say my technique was great but the patient died is of little comfort to the patient?s loved ones. So, adopt the philosophy that there are only business leveraging projects and no IT projects. These projects may have an IT component but they do not belong to IT. The closest thing to an IT project is one of pure infrastructure and even those can only be justified in terms of how they position the business for success and sustainable growth. If you doubt this just ask the CEO his or her opinion. Never be the project manager of the project. Assist the user in managing the effort. You can be the technical PM but accountability must be shared by the user for success. Focus on helping the business define, design, build and deploy the right systems and then recommend processes that have the greatest chance of supporting success. Be outcome driven and process focused. Saving Changes...
Re the last few posts. This area is always interesting to read about, and frustrating when you're in the middle of it.
One of the best roles I've been in that addressed this, was Change Manager for a global merchant bank in Europe. They were heavily IT dependent, and invested a great deal of time and money in IT systems. My role as CM was to sit between IT and the business to ensure projects were business driven, and ensure techies didn't go off at a tangent developing out of spec requirements, i.e. IT driven.
One particular project that went live just after I joined, fell over after 3 days in the production environment. Given the task of finding out why, I discovered a real lack of end user involvement during requirements definition, and just as bad, end user testing. $30m US nearly down the drain! It was eventually rescued and I put some new practices in to place to ensure it wouldn't happen again, including identifying the support and maintenance work required (business and IT), following implementation - this was done during the development phase, and maintained throughout the remainder of the project. Sounds like common sense, but you'd be amazed by the amount of organisations that don't consider operations post implementation, resulting in increased admin & support work = cost. Good PIRs should pick this up and feed back in to Project Management methodology - good old continuous improvement.
This is what can typically happen if IT see themselves as the owners of the project rather than the business - business end up being the car and not the driver. Trouble is, the business ends up paying for the whole thing including insurance, registration and repair bills! If you're paying, you should own it.
All projects should be business driven - as Mike mentions below, even IT infrastructure projects are a consequence of aligning IT with mid/long term business strategy.
PIRs are usually difficult because people want to move on to the next project - "we've done that, let's forget it" seems to be the norm. Make sure mechanisms to capture project data for use in PIR are addressed and put in to place when you're scoping the project, not half way through or and the end. The PIR becomes far less painful because you already have a great deal of info without chasing.
"I do not know anyone who has got to the top without hard work. That is the recipe. It will not always get you to the top, but should get you pretty near."
