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.


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.



Justin James is the Lead Architect for Conigent.

Tony Hopkinson
Tony Hopkinson

Is the so called alignment thingy. The them and us, or us and them :p While we are concentrating on projects with business priority and are ubnder resourced, lower priority projects quite rightly are not going to get done. The real problem is, are the business priorities correct? Are they being set based on what's real, has the information required to make a decision been collected and analysed. Are the consequences of the options understood? Are the people making the decisions whether they work in eth IT dept or not, competent? It's not up to us to direct the business, blocking time off for low priority tasks, is no different to "going off on one" and doing something that doesn't fit the business need. There is no Business and IT, that split is artificial, you can't do business in the modern world without IT (where you get it from is irrelevant to this argument), and without business there is no need for IT. Joined up thinking, collaboration, clear headed assessments of where WE are and where WE want to go, is what's needed. All else cya , window dressing or just complete bollocks. If it doesn't promote making the best profit you can over the long term, it shouldn't be done. The only relevance of which part of the business came up with the idea, is who to reward or penalise.


I agree with a lot of what's been said and tend to think of IT work fitting into a framework with three specific types of work: Emergency, Normal Maintenance, and Project Work. You can then envision these in a pyramid with the top of the pyramid being emergency work, then maintenance, and at the bottom project work. The most critical work is at the top and keeps the doors open. Each chunk will have a certain percentage of resources to keep it going. So if the top two are 20% and 20% respectively, then 60% of your resources can be committed to projects. For projects, I think the best way to go about it is to create a list prioritized by representation from the various business units (including IT). IT can then create a strategy to commit resources to the various projects. You could have a small amount of resource commitment towards each project and all projects will take a long time to complete. Or you could focus the most attention to the highest priority projects and work towards completing them quickly. One thing I don't agree with is to set aside time to work on low priority projects. If the business as a whole agrees (through the prioritization process) which projects are of most importance, then the department(s) that have low priority projects should either accept that or make a better case that their project should be higher in the list.

v r
v r

1. I must add that as a former IT development manager and a project manager, scheduling work is done best when IT AND the enterprise management team all know what the corporate project priorities are. This holds true for small, medium and large companies. 2. Accurate status communication from IT is imperative. There is only shame in dishonesty. If the development manager(s) are dishonest with themselves about the time and/or resources, the project/program may be in jeopardy of failing AND the development manager(s) do not get a chance to revise their estimates when they see all the factors they should have used to make their initial estimate(s). Learning is good. Accurate communication is good. 3. Anytime projects/programs are initiated within an organization (department level or corporate level), the decision makers must know how much of their resources (human time, machine time, network burden, etc.) are commited to "keeping the doors open" and routine maintenance. Otherwise, nearly every project/program will be late or fail. This last item should be included in the project/program assessment of the critical success (a/k/a risk) factors related to the computing environment. It should also be part of the project/program requirements so decision makers have a more accurate picture of the total cost(s).


Too often, an IT unit is viewed as a money pit, an annoying overhead standing in the way of Real Business getting things done! In reality, IT units are generally underfunded and are asked to operate with only enough staff to perform maintenance and respond to outages. They are rarely permitted the ???extra??? staff required to handle the uneven resource demands of projects. Yes ??? I come from an IT background. I am also a project manager and I agree that working with some IT teams can be frustrating. They don???t run their shops as a business. Scheduling, when it is done, occurs on a white board in someone???s office. It???s time for IT units to start taking themselves seriously and for business to do the same. Business units (projects) should: (1) work with IT to determine the resource requirements (quantity & duration) and (2) formally schedule the work. If the project timeline slips, notify IT and work with them to reschedule the tasks. On the other side, IT units should be scheduling their work just like projects do. Critical path analysis and resource leveling should be commonly used terms in IT management. Run IT with the focus and structure of an independent business unit that is responsive to a customer base. Make realistic commitments and deliver to them.

Tony Hopkinson
Tony Hopkinson

Not a new idea, been there, done that, didn't work. One time they initiated a plan to do work for other businesses, made a better profit on external jobs, and therefore gave all the internal businesses a much lower priority.... Take on huge administration burden simply to show the business how complicated managing IT can be, try talking to them instead, it's cheaper.

Editor's Picks