Managing projects in a multitasking environment
This seminar provides a process for resolving a common problem in IT – employees are working not just on multiple projects, but on normal operations at the same time. Everything is a Number 1 priority, and what gets worked on depends on who has the loudest voice this week. Everybody, team members and project managers, are stressed and projects are accomplished very inefficiently if they are completed at all.
This seminar describes a four-step process for making the appropriate changes in the organization to select the most important projects, prioritize them, allocate them across the available resources, and build in enough time for daily operations and for crisis management. It begins with a common master schedule and then builds on that start to effectively manage the entire portfolio of projects. The end result is a more efficient method of utilizing resources and ensuring that high-priority projects are completed efficiently and effectively.
Traditional project management assumes that we have a dedicated project manager and dedicated team members. The team members may be either on the project for the entire project, common in large aerospace development projects, for example. Or the team members may be on the project for specific durations, but are fully dedicated to the project while they are on the team, common in many matrix organizations. However, neither of these situations are common in many IT projects.
In many organizations, the IT group is involved in day to day operations, as well as working on projects. And not just on one project, they are often involved in multiple projects, all in different phases at the same time. From the team standpoint, there is a never ending stream of projects they have to work on. From the standpoint of the executives, there is a high rate of failure in IT projects and the ones that complete rarely do so in the time expected.
This too-common situation is a recipe for disaster. Team members are overworked and stressed as they switch from one project to another and back to operations. Priorities keep changing from week to week and the team members work on whatever the last person to stop by their desk asked them to work on. Projects are dropped when an operational emergency arises, such as a software virus infection. Everybody is so busy working on current projects, there is no time to adequately plan upcoming ones.
In no other field of project management is the work so continually interrupt-driven. Team members work on whatever the last request was. There are multiple project managers, each of which is managing multiple projects as if they were the only projects in work. The project managers have uncertain authority and act more as expediters or facilitators than true project managers. Projects just stumble through the system with problems at every stage.
One aspect of IT management that cannot be overlooked by project managers is the vast number of bug, viruses, and worms in Microsoft Windows systems. While it would be tempting just to say that this is part of normal operations, the practical reality is that it takes large amounts of time to deal with them. One analyst with CIO Magazine scanned 550 machines with patch management software, which told him to apply 10,000 patches. Researching each of the 4,200 vulnerabilities published by CERT in 2003 for 10 minutes would have required one staffer to research for 17.5 full workweeks, or 700 hours. Also in 2003 Intel applied 2.4 million patches to its own network. (Berinato, 2003) These numbers illustrate the Wild West environment that many IT organizations live in. An environment that makes project planning very difficult. Project schedules are subject to a lot of interruptions that the project manager has no influence over.
Another way in which IT is different than most project areas is that team members are truly a team only within IT operations. That's the only constant they have on a day-by-day basis. Projects may have groups of people working on them, but these are not teams, as we are trained in project management to think of the people working on our projects. They don't change their desks or their reporting relationships, they work on multiple projects, and their allegiance to a project manager is highly temporary.
The normal working environment in IT is not understood nor appreciated by upper management in most organizations. There is a tendency to say “Yes, we can do that.” when a request for another project is made, with no understanding of what is required or the existing capabilities of the organization. In queuing theory there is a well-known law, Little's Law, which states that when a system is running at maximum capacity, adding more work onto the system only slows it down, more formally stated as cycle time equals work in progress divided by the system's throughput. There is a multitude of research that shows that this working environment is highly unproductive, with efficiencies being lost at every change in work effort. An environment which can be made worse only by locating the project team members in low-walled cubicles, subject to interruption by every telephone call within 20 meters.
Insurance Company Situation
While this is generally true in many IT organizations, the worst case the author has seen was at one large insurance company where the author consulted. We faced the situation where we had a corporate IT department that was responsible for corporate-specific IT systems and supported multiple divisions as needed. There were approximately 170 members in the IT department and 5 project managers in the PMO reporting to the author. There was a major shift to consolidate the division-specific IT needs into the corporate group, a very high visibility project, and one that was resisted by several of the divisions due to poor experiences in the past with corporate IT meeting their needs in a timely manger.
While this was a complex enough environment, it was made worse by poor planning at higher levels of the company. There was absolutely no knowledge of what projects were in work or needed. After the PMO did a survey of all the divisions and entire corporation, we determined there were over 100 projects in various parts of the queue, all having different and shifting priorities. Another serious problem was created by a newly hired executive who demanded that the PMs be fully aware of every aspect of each of their projects, even if they were responsible for two dozen projects. The PMs spent so much time just trying to find information in this confused environment that they had absolutely no time to actually manage anything.
In addition to a confused and highly political corporate environment, the technical environment was also highly complex. It included several mainframe systems, a large local area network, and a variety of web sites. All this had to be maintained on a daily basis and upgraded as needed. The mainframe group was in the middle of an operating system upgrade, and estimated it would take more time and resources than they had available, so wouldn't be able to support anyone else's projects for several months.
An additional constraint was that corporate IT work was paid for by the divisions, each of who put in a percentage of revenues to pay for the IT infrastructure. Since the divisions differed in size by an order of magnitude, the larger divisions had the most input into how the money was spent and the smaller divisions had little priority. This threw a complication into the solution that made it difficult to satisfy everyone and still complete projects.
Finally, there was the issue that nobody had knowledge of what the resources were working on. Not one person could state what percentage of resources were working on daily operations, bug fixes, or any projects. A truly interesting environment in which to create a PMO.
The standard approach to a situation such as this is to buy a software package where everyone enters their time and projects are then managed by the PMO using the package. While this is a necessary effort, it is only part of the approach and can take many months to implement effectively.
In order to approach the highly confused state of affairs that we faced, the first step was to understand what the people in IT were working on. Since they were not used to entering their time into a time-keeping system, this was chosen as the first step in order to understand what time was available for projects.
This was accomplished by writing a simple piece of code that was kept on the server. Everyone in the IT group was trained on entering their time on a weekly basis. In order to keep it simple, there were only four categories of activity defined:
- Core work (daily maintenance and minor upgrades)
- Bug fixes and virus responses
- Project work
- Miscellaneous (all work not fitting into another category - training, sick time, etc.)
Once we had collected just a few weeks worth of data, we were able to draw the pie chart shown in Exhibit 1:
Exhibit 1 : Average IT Daily Work Efforts
In collecting these activities we discovered the following breakouts:
- PMO – 100% dedicated to project work
- Corporate Information Security Office (CISO) – 90% dedicated to project work
- IT Architecture Group – 40% availability for project work
For the other teams, the work broke out as follows:
|Average||Mainframe Systems||Network Team||Web Team|
|Project Work||35%||50% *||20%||35%|
* The Mainframe group showed as 50% available for project work, but that included a major upgrade project they were working on internally.
Once we knew how people worked on a daily basis, we could take the percentage of time available for projects and allocate it according to project priorities. (See Exhibit 2)
Exhibit 2: Expansion of Project Work to Projects
Step 2 – Determining Available Resources
Before we could allocate resources to projects, we had to determine what resources were available. Based on the availability numbers we collected and an average work-month of 21.63 days (taking into account vacation and holidays), we came up with the following availability figures:
|Working days/month||FTE* Days/ month||Project Multiplier||Resource Availability|
|Mainframe Data Ctr||35||21.63||757||0.50||378|
* Full Time Equivalent.
One of the problems this organization had, like so many others, was the management kept making promises on how many projects could be worked on. They saw almost 11,000 days per quarter of available staff. They did not see that that majority of that staff was already busy, and there was less than a third of that labor force actually available for project work. These numbers created some excitement among management when it became obvious what areas people were working on. What was especially interesting was that the majority of the Network Ops group's time was spent in bug fixes and fighting viruses. This was a much higher percentage of time than had been appreciated.
Step 3 – Capturing Projects
While this was going on, the PMO did a survey of what projects needed to be done. When the author was developing a PMO for Toyota USA, the PMO team was able to quickly identify 35 projects that were either being worked on or were waiting to be worked on. Priorities were obtained from the executives who served as project sponsors.
For the insurance company, the process was much more complicated. Corporate IT had their own set of projects and priorities, other corporate departments, such as HR, had a set of project and priorities, and each division had its own set of projects and priorities, a total of nine separate entities. Several weeks were spent in the survey process and the result was a list of over 100 projects that were:
- Being actively worked on
- In analysis
- In queue waiting for analysis
The list of projects in each of these three stages was then prioritized within each of the corporate entities.
Normally, at this step, the projects would be prioritized into a logical set. Regulatory-drive projects would have highest priorities, badly needed infrastructure upgrades would have second priority (usually), and discretionary projects would have third priority. The discretionary projects would then be further prioritized depending on how they satisfied corporate strategic objectives. This was not the process followed here, however. The corporate IT department prioritized its own projects and those of other corporate departments, but each division was allowed to prioritize its own projects however it wished, and there was no priority-based deconfliction process that coordinated all projects. Instead, each division was allocated a percentage of available labor and they could determine which projects they needed worked on based on the available labor pool.
Step 4 – Allocating Effort
At this point we had a list of projects in work, in analysis, and in queue waiting for analysis.
But we now had to make a determination of how much of our scarce resources could be taken away from doing project work (non-project work had already been removed from the calculation) for analysis. Based on experience in other IT areas, a figure of 15% was chosen. This was removed from the available project hours and allocated purely to analysis of upcoming projects.
So our availability matrix now looks like this:
|Orig. FTE Days/ month||Resource Availability||Needed for Analysis||Project Work Availability|
|Mainframe Data Ctr||35||757||378||57||321|
This shows that the available resources are far less than looking at the organization chart would show. But it was very realistic, based on past experience in the organization.
At this point, we could take these resources and allocate them across the projects in work. The project managers had provided work breakdown structures for the projects either in work or in analysis and we compared the skills required with the available resources in the different organizations.
There were two ground rules we followed:
Daily operational work took priority over project work. This meant that operational problems would be fixed as quickly as possible. It also meant that project schedules were subject to delays depending on what operational issues occurred during the project.
The second ground rule was that no project could be worked on until resources were freed up to work on it, and no project could leave the queue for analysis until the resources for analysis were available. This ground rule was based on experiences the author had at a major car manufacturer when he designed the PMO there. Projects were started in order to be able to say that they were being worked on, even though no work had actually been done on them.
In order to simplify the calendar scheduling of resources across the groups, we determined the primary areas each project impacted. Projects that were mostly mainframe-related generally had little impact on the Web group or the Network Ops group, and vice versa. This allowed us to schedule the primary resources first and then negotiate with the other groups for resources needed in their areas.
The first approach was to create the following spreadsheet to allocate projects across all IT areas and project out project resource needs for upcoming months. This looked like:
This allowed us to project out our overall resource needs for the next few months. Remember that the hours/month we're using here are just those that were available to work on projects. Maintenance work, bug fixes, and other operational work had already been removed from the equation.
While the process was simple enough to do for one group or one division, it became extremely complex when spread across multiple divisions with differing priorities. We discovered that the simple projection, made above, was not adequate to provide enough detail in each area. The skill sets in the mainframe group were totally different than the skill sets in the Network Operations group, so cross-substitution of resources was not a viable option.
Since this was more complex than our simple spreadsheet approach could handle, we turned to a monthly coordination meeting where each division was given a single vote. They had to agree among themselves what the resources would be spent on. In order to counter the influence of the larger divisions, each division was given veto power and no decision could be implemented if it was vetoed.
Adding more detail in each group to the above matrix provided the following spreadsheet:
This was detailed enough for our purposes. While the above is a simple example, the actual spreadsheets covered the upcoming twelve months of activity, included the work that needed to be done in the different divisions for each project, and included other information such as points of contact.
IT type projects are different than projects in most other fields of project management. While most IT projects live in an environment of multiple projects, with project teams bouncing from working on one project to working on another to working on daily operations, the situation faced at the insurance company highlighted here was the worst the author had found in 25 years of project work. A complex technical environment was made more complex by a high degree of politics and poor decision-making by management.
Despite the obstacles, we were able to develop an effective means of identifying the resources available for project work by identifying and separating out all the non-project work. A percentage of the remaining resource availability was taken for project planning and analysis efforts, and the remainder was allocated across a variety of project priorities by the different divisions within the company.
Berinato, S. (2003, November 1) Franken Patch, CIO Magazine 17(3) 100
© 2004, Frank Parth, Joy Gumz
Originally published as a part of 2004 PMI Global Congress Proceedings - Prague