CXO

Break the cycle of project push back

Justin James advises development project managers on how to resolve issues with clients and IT departments about workflow processes.

I have observed a number of instances in which the clients and customers of an IT organization have a tough time following the workflow. The IT organization tries to get control over the situation so they impose rules, forms, paperwork, or some sort of IT-managed checkpoints in the process. The customers do not seem to have their needs met, and they request exceptions. Pretty soon, the exceptions become the rules, and there is a total breakdown again. This pretty common pattern repeats for far too long.

The trick to fixing this situation is to understand the underlying issues. What I usually see is that the clients are being required to hit a metric (e.g., sales numbers or customers helped per hour) that they need the IT department to help them meet. But the IT department does not help just that one client, so they have their own priorities.

This is where the problems arise. Each client has their own priorities that are relative to only that one client, while the IT department's priorities are relative to the entire company. To make matters worse, companies tend to focus on the project and departments that generate revenues, so certain projects and clients are always de-prioritized by IT to the point where the work just sits in limbo. Meanwhile, the clients are being evaluated on a metric that needs the work to be done in a timely fashion.

It is a really unfair situation to everyone. The response from clients is to find a way to circumvent this process, typically by either working with IT outside of the established channels, or by short circuiting the system by getting the ear of a decision maker.

What you can do to break the cycle

First, you need to go to the overall business management on behalf of the clients and projects that get pushed to the bottom of the pile, and make it clear that the slowdowns are in IT. The business has been hearing from the managers, "IT hasn't met my needs" for so long it is a tired horse. They need to hear from IT, so it is on the table and everyone understands what is happening. This allows the business to separate the performance metrics from the de-prioritized projects. In turn, the responsible managers will no longer have the need to go around the established process. It also allows the business to see how their prioritization affects the overall business.

Next, you need to establish some way of ensuring that even the low priority projects get completed. The best way to do this is to block out time every day or every week to work on these projects and stick to that schedule without fail. Unless there is a critical system emergency, treat this time as totally committed to these projects, and take it into account when scheduling higher priority projects.

Along the way, get in the habit of providing regular status updates. Much of the tendency to micromanage comes from the fact that clients feel like they have no insight into their projects, and the only way they know what is happening is to inject themselves into the workflow. By giving them regular status updates, clients know what to expect and can make the right decisions. Clients would rather hear "we're running 20% late" than hear nothing at all but have the project be 10% late. By letting them know what is happening on a scheduled basis or on a milestone or "status changed" basis, clients do not need to be getting overly involved in the projects.

Finally, you need to make sure that your process is a lever for the business to get results, not a crutch for IT to fend off requests. We see this all the time in IT; the department is overwhelmed so they conjure up a process that doesn't help work get done, and it makes it more difficult for work to be requested. You need to have a process that doesn't just accept requests and eventually spit out finished work but helps IT, the client, and the business overall shepherd the work through. An important addition is to have someone in the IT department be involved in the business side of things and act as the "voice of the customer." It is easy to develop an attitude of "us against them" as part of the push for realistic timelines, but having that deeper understanding of what happens on the customer's side is important because it allows the IT side to see what the real needs are, as well as to humanize both sides.

Conclusion

At the end of the day, IT does not exist in a bubble cranking out code; it is a tool for the business to keep the lights on and generate more profits. If IT acts as a roadblock to these goals, the business cannot be successful.

J.Ja

About

Justin James is the Lead Architect for Conigent.

Editor's Picks