Six Steps to Successful Sponsorship
Know and communicate the business goals. What will the project cost, and wh1t are the returns? If you don't know where you're headed, you won't know whether you've arrived at the right place.
Get users involved early. The best time to involve users is at the definition stage. No one can do a better job of telling you what they need from technology than the people on the front line; there's no sense giving them a new e-mail package when what they really need is a phone.
Manage the risks. Business risk: If the project's ROI is based on winning new contracts, what happens if you don't win them? Technical risk: Is the project based on mature or bleeding-edge technology? Good projects have fallback plans; good sponsors know the risk level and the fallback plans before they sign up.
Keep one eye on the scope. Once the goals are defined and the functions of the system are targeted, hold them steady. Require a business case for making any significant changes to a project that's already underway.
Put accountability in the right places. Don't accept IS excuses for late delivery. However, it is up to the business line to use the system and achieve the business goals.
Get people excited. If they believe in it, they'll usually find a way to make it successful. If the benefits are not obvious, you may want to sweeten the package with new desktop systems or a new service that users will get excited about.
Successful Implementations Rely On....
IT'S NO SECRET that end users can make or break an IT project, and the IS department sometimes don't have the clout to force difficult projects through. To the rescue: the executive sponsor, a line-of-business VP or department manager (depending on the scope of the project) who rallies the troops and keeps the project on track.
"Without a sponsor, the project will die, and if it doesn't die, it becomes a very painful, 'We told you so,' nonvalue-added series of meetings where people point fingers and IS becomes the bad guy." But for a business exec with no technical background, spearheading an IT project can be intimidating; often the role amounts to nothing more than an occasional mug shot and a generic quote in the corporate IT newsletter.
That won't cut it. Successful technology projects--particularly those that demand a great deal of change from the workers who will use a new or revamped system--require executive sponsors who step up to the plate and swing away. The good news is that much of what the job requires is familiar territory: Standard project management procedures, like spelling out clear goals and putting in place the right accountability, still apply. "You don't have to be a technology whiz; you just have to be a good manager and treat it as you would any other investment."
Still, there are a few twists to a technology-heavy project. The following tips for successful executive sponsorship are gleaned from business people who've been there, done IT.
Business Goals
Know how your project will benefit the business, and make sure you communicate those benefits to the employees who will use the technology. Poorly defined goals doom a technology project; well-defined goals help keep all project personnel working together. The system with unclear business benefits is one better left unsponsored and undone.
User Involvement
Getting user buy-in requires more than just communicating benefits. It also helps dramatically to enlist users' collaboration in designing or selecting the system.
To convince business line managers to lend their workers to the front end of a project, executives recommend talking to their wallets.
Risk Management
Every I.T. project faces risk, whether it is technical (caused by unproven technology or integration problems) or business risk. Veterans say project sponsors should not only understand the risks but also demand that contingency plans be put in place before the first nail is hammered.
But even though risk management is a project management basic, it is easy for executives with little technical knowledge to ignore it because they are intimidated by the technology. Fortunately, they also say technical risk is easier to manage than business risk. If the project hinges on a relatively new technology, it makes sense to build and test a prototype before going whole hog.
Scope Management
Keeping requests for new features from derailing or slowing down a project is a step that should be handled by the project manager, but occasionally the executive sponsor has the clout to say no to a request the IT leaders can't refuse. Besides inflating costs, scope creep can deflate user enthusiasm as the project's benefits are pushed off. Getting the project done quickly is a good goal for the executive sponsor to champion; bells and whistles can be added later, after the initial rollout. "Vanilla is a very good flavor"
Appropriate Accountability
No accountability, no progress--that's no surprise. The challenge in IT projects is to hold the right people accountable for the right deliverables. The IS department's job is to hand over the specified level of system functionality by the due date. After that, it's up to the business workers to get the specified business benefits out of the system. And the executive sponsor should make sure accountability is in place to enforce that division of labor.
Non-IT execs have a tendency to exaggerate the role IS workers will play after a system is rolled out. As a result, it is common to point the finger for system failure at IS. That gives the other employees less incentive to make the new system work.
IS and business line workers develop a lot more synergy when both feel an equal burden of responsibility.
Helpful Hype
Amidst all the spreadsheets, numbers, risk analyses and so forth, remember to add a spoonful of sugar for those who will actually have to use the technology.
In addition to getting users to help define system requirements, don't be afraid to use a little old-fashioned hype to move the project along. Build up a level of excitement, by publishing team communications on a weekly or monthly basis, saying, 'This is your destiny.', etc...
RELATED POST
INNER JOINS WITH THREE INTERNAL TABLES IN SAP ABAP REPORTS
Inbound process over view
What is a Idoc?
Outbound process overview
Outbound process via message control
EDI outbound process
No comments:
Post a Comment