There never seems to be an end in IT, particularly in corporate IT, to balancing competing priorities in the form of seemingly endless work requests. How many times have you been involved in this typical conversation?
Business: We need these 10 changes implemented as part of this project.
IT: Ok, you put that project on hold a few months back, but we can dust off those 10 changes and get working on them.
Business: How long is it going to take? Before we put the project on hold it was supposed to take one month of development.
IT: Yes, but a number of other projects have changed the systems involved since the project was put on hold. We will need to do some analysis and get back to you.
Business: <reluctantly> Ok.
<Analysis occurs amongst technical people and a whiteboard>
IT: In order to meet all 10 requirements, it is going to take two months of development.
Business: What?!?! Before it was going to take a month, now two months, why double?
IT: Well, because of the FlimFlam upgrade project, we need to rework two of the interfaces in order to meet requirement number 7.
Business: Without requirement number 7, how long would it take?
IT: We’ll need to go back and rework the estimate because the development effort involves meeting requirement number 7.
Business: <clearly frustrated> Ok.
<Re-analysis occurs amongst technical people and a whiteboard to remove requirement #7>
IT: Ok, without requirement number 7, it should only take three weeks.
By this time, all project stakeholders are frustrated with each other. Tension amongst everyone is high and any misstep going forward has the potential to erupt into a finger point/blame session over tiny deviations from the plan.
Is there anything that can be done to avoid this repetitive negative pattern?
Sure, just implement one of the Agile or Lean methodologies and all your problems go away. Continuing to use the Waterfall methodology will place you in this situation time and time again.
But what if your organization, as a whole, is not in a position to implement anything but something akin to Waterfall?
One of the major challenges for any manager of project delivery focused resources is project sponsor expectations management. Unless you are blessed with a very strong project management office, you are most likely stuck with this loathsome duty to some extent.
In your typical corporate project delivery structure, IT is resource constrained compared to all of the work the project sponsors desire. There exists some process function to try and prioritize the work in some manner (by ROI, revenue generated by business unit, charge back mechanism, etc.) Even with all this in place, you still have aggressive project sponsors that are trying to keep their goals and objectives marching forward at all costs. Some partner well with IT. Some, well, are ever so difficult to keep satisfied.
I can’t say I’ve found the silver bullet that makes the challenges of project sponsors evaporate, but I have found some techniques to reduce the frustration:
Overly communicate on project priority changes
When you find your team members re-directed due to a shift in the priority of projects, take the extra step to remind each project sponsor of the “cost” of this change:
“I just wanted to share that due to the corporate priority committee indicating that the FlimFlam Upgrade project now takes top priority over your project. Due to this action, any communicated delivery dates for your project are now no longer valid. Also, since technology will likely change as a result of this shift in priority, your project will need to incur additional time in order to re-evaluate the technical solution and then new dates estimated.”
Don’t assume the project managers will update their project sponsors.
Communicate cross-project impacts regardless of sponsorship
More than likely, your team is a shared pool of resources that is assigned to a variety of projects. Expecting your project management function to keep track of your resource contentions is hoping against hope. You are relegated to keeping track of who is working on what for whom and all of the interdependencies between projects. As one project plan gets turned to mush with changing requirements or delays on the business side, feel free to pass that information on to the projects that you team member is also assigned. Unless you own the project management function, don’t assume the project managers are sharing this type of resource conflict information cross-project.
Communicate Work Breakdowns with Schedules
When working with your team to communicated major dates back to project teams, in additional to communicating estimated delivery dates, also attach work breakdown structures to go along with those estimates. Make sure to include all possible (realistic) information that might be stressors on making those dates. You may also want to consider projecting out the work schedule over a calendar. This way you can add in buffers to handle all of events and activities that cause people to get distracted from focusing on their project work. I’ve written before about considering a 5 or 6 hour productive work day for your team members. Or if your team member has an additional assignment to learn new technology or do some cross-training with another team member, factor time for that work into the project work schedule. A 10 hour blob of work for a given resource may need to be started on a specific Monday and not actually be completed by the end of the day the Friday of that same week.
These considerations are far from guaranteeing a stress free existence for your delivery focused team. Rather, with enough re-enforcement of the detractors that impact your shared resources from being true dedicated project team members, project sponsors shouldn’t be lacking for information. This information should reduce the potential for what I call the “surprised and confused” reaction and allow you to focus on your team’s real goal: delivering solid, working technical solutions that meet the project requirements.