Bob Lewis
Columnist

Three-ring project

analysis
May 2, 20035 mins

Dear Bob ... We're starting a major initiative to replace a legacy custom enterprise application with a financial package and a custom integration system. The business team is having serious difficulty defining requirements and specifications because of a lack of strong leadership and a very good but recalcitrant middle manager. A couple of managers keep demanding th

Dear Bob …

We’re starting a major initiative to replace a legacy custom enterprise application with a financial package and a custom integration system. The business team is having serious difficulty defining requirements and specifications because of a lack of strong leadership and a very good but recalcitrant middle manager. A couple of managers keep demanding that the team “consider” (read: design for) every possible scenario, regardless of how “real” or their frequency (the 5% solution). This is affecting our ability to make progress as a team on meeting the real business objectives. We generally have a good relationship with the business partners; however, there are currently many chefs in the “strategic” kitchen.

I’m the lead IT PM on the initiative. Do you have any ideas on effective ways to get around these disruptions, or proactively address the exception scenarios with a reasonable timeframe, to help keep the project moving in the right direction? Or should I just stand back and watch the fur fly?

– Flying Circus

Dear Flying …

From your description, the root cause of this problem isn’t a disruptive individual. It’s that while everyone is accountable for a part of the process, nobody is accountable for successfully changing the business. That is, your accountability is limited to successful implementation of information technology while the “business team” is responsible for various business design issues.

This helps prevent good design decisions.

Here are a few steps I’d suggest you take which should help put things back on track:

* Schedule a weekly meeting that includes the executive sponsor, the manager of the business team, you, and nobody else. In this meeting, nobody worries about official role – all three of you consider yourselves accountable for the success of the entire initiative. It’s also a “safe” meeting: Each of you can speak freely, knowing the conversation will be held in confidence. For the situation in question, intervention by the executive sponsor may prove necessary.

* If there is no executive sponsor, escalate to the CIO if necessary but make sure someone in the business signs up for the role. Otherwise, it’s safe to predict the inevitable failure of the initiative. Executive sponsors, if your company isn’t familiar with the concept, must have sufficient authority to make decisions, which is to say they must be in a position to secure funding, determine schedules, and assign or reassign staff. Everything else isn’t a decision – it’s just talking.

* Coach your business PM counterpart on the necessity of formalizing the decision-making process. It’s perfectly fine for someone to ask the team to consider any and all issues. Well, not any and all – that can turn into a filibuster – but lots of ’em. It’s equally fine to subject each one to the decision-making process, which should include an escalation framework and definition of final authority.

* Schedule a joint business/technical team meeting (scripted in advance by you and the business team PM) in which you establish a few new rules of the road:

– Everyone on all teams should consider themselves responsible for the success of the entire initiative, not just their tasks or their team’s deliverables (sound familiar?)

– 80/99: This is like an 80/20 but designed to snare the troublemaker. The team’s goal is to anticipate the 80% of situations that will encompass 99% or more of all real-world situations, and to determine one general-purpose work-around for employees faced with situations the system won’t handle once it’s installed. Another way to frame this: The current system doesn’t handle everything either, so the goal for the 1.0 installation is to handle more than the current system does.

– There will be a 2.0 and 3.0 project, staged for 6 month deliveries of delayed features and capabilities (establish this with your executive sponsor first so it’s firm). That way, lots of the small “requirements” can be quickly relegated to later releases rather than the only alternatives being approval or rejection. The dialog can quickly become almost automatic: “We’re marching toward a tough deadline. Is this important enough to potentially push it out further, or can the company wait on this until the next release?”

* Either you or the business PM needs to take the disruptive middle manager aside and let him or her know the impact of his/her style. Be positive: “I know your goal is to make sure we don’t miss anything important. What you don’t realize is that the overall impact is that it’s causing people to ignore you. You’d be more effective if you’d focus on fewer issues, and make sure the ones you raise will really cause problems for the company if we don’t address them.”

There are no guarantees, and I’m unencumbered by any knowledge of the nuances of the situation. If these suggestions don’t work, explore other ways of dealing with the issue in that meeting with the business PM and executive sponsor.

And if you don’t have an executive sponsor and can’t get one … run like hell, because I can almost guarantee a train wreck, and you’ll get blamed for it no matter what really went wrong.

– Bob

——–