Managing the IT Project Backlog
While IT seems to be an exercise in reading the future and transforming it into business processes, IT often misuses its most vital resource—the people that turn hardware, software and networks into business applications that improve productivity, provide new function, and increase employee effectiveness. Analysts are pulled off projects barely halfway complete, designers are reassigned to new projects because their current one has had its priority downgraded, and programmers struggle with foreign development tools to enable business processes like accounts receivable they’ve never worked with. It’s a horrible waste of talent and money.
Backlog management is a most challenging aspect of managing an IT operation, an exercise of determining what IT resources—hardware, software, network, developer, programmer, etc.—will be needed to meet a particular project’s requirements. Thorough assessment of the changes or new function involved is required to determine the necessary amount of programming and development resources for each project in the backlog, based on both technical and business skills, then compared against existing resources to determine whether sufficient resource exists.
The amount of IT resource assigned to a project must also be based on the value it will provide to the organization, a metric that involves both IT and user management input, effectively a form of return on investment which determines a project’s importance and priority. Other factors are experience, availability and skill level of staff. I worked in an organization where the philosophy was “a body is a body,” so their assignment methodology was to assign the work to whoever had the lesser workload or had management’s favoritism. That’s a formula for disaster.
Backlog management is a constantly moving target, and while project importance is an important factor, it’s also an assessment that varies as business changes, staff evolves, technology advances and changing business priorities usurp. It involves hardware, software, designers, analysts, programmers, schedulers, vendors, clients, documenters, testers, planners and managers, which comprise a whirling dervish of players that must be coordinated, assigned, measured, and teamed together in a concoction of IT professionals and projects producing deliverables.
Establish a Project Sizing Infrastructure
A backlog administrator position must be defined to run the backlog management process; for small IT units, it may be part-time, and for larger operations, it may be a full-blown department. It’s the backlog administrator’s job to build and maintain a project status and resource consumption database, represent backlog management in development projects, and provide resource skill and availability status. The backlog administrator is an advisor, sometimes an arbiter, and may also take an educational role, acquiring and providing training based on project requirements and progress.
Creating a backlog database for resource usage and project tracking is no trivial matter. It involves implementing database software (I’d choose relational); IT can help with that. The real challenge lies in data collection and entry of projects and their status, resource allocations (hardware, software and person hours) and other metrics. A lot of time will be invested in interviews and project reviews.
Each approved project within an IT backlog will require a blend of previously-mentioned resources, and those resources—whether measured in person-hours, disk storage, processor cycles or bodies—must be subtracted from the backlog’s resource pools. A pre-requisite to backlog management is to establish starting values for all existing resource pools, tally total resource for each pool and current consumption of each resource, the subtraction of which reveals available resource. During this assessment, add a fudge factor; as a general rule the estimate will always be low.
Assessing a Project’s Requirements
Once the backlog management infrastructure is in place and existing projects’ resource consumption is estimated, the base is established for new projects. Current projects may be re-assessed when major modifications either increase or reduce their scope. In all these circumstances, having a good project management discipline in place is a significant advantage, because building a project plan can simultaneously calculate person hours as accurately as any methodology. In fact, the project management and backlog management systems can be combined into a single, interacting system.
But often an IT department isn’t willing to expend the effort of producing a project plan just to scope a project, so alternate methods can assess the effort and skills needed to perform tasks. Developing a historical database of hours expended and skills required on different projects—even when based on participants’ estimates—is invaluable information. The more detail that’s gathered, the better, and members who’ve worked on the various programming activities or other undertakings of the past often have a remarkable recall for detail. Basing assessments on historical data can be quite effective when other data isn’t available.
Implementing Backlog Management
Having implemented a backlog management architecture and populated it with existing projects and applications, it’s time to evaluate new projects and integrate the process into standard IT operations. As new project proposals arrive, a project backlog administrator should be invited to high-level discussions and reviews, which allows the backlog member to begin a resource pool analysis, and to query designers and analysts on resource availabilities. This prevents surprises on staff commitments and shortages, allowing adjustments as necessary.
Resource Allocation
Not only does a project backlog assessment estimate the amount of resource a project will require, it also determines the hours and skills that will be assigned to programming, testing, user interface and other IT functions. The project backlog administrator should not be the person who decides where and when resources get allocated, only what’s needed. Particularly regarding personnel, those decisions are made by unit or department managers, but the backlog administrator should clearly delineate options and consequences in writing.
Ongoing Operations
Periodic reporting is a must. Creating an electronic form and program to automatically update the database, combined with weekly updates, can keep the database current. Once in place, relational queries can constantly monitor resource pool usage and availability, and periodically update various pools as projects start, complete and progress. A backlog representative should regularly attend most project reviews to provide input or advice when requested, and to update the database. This also incents project managers to keep project plans current, to be fully informed on project status, as well as providing current project proposals and status of available resources.
As the assessment and development processes continue, the backlog administrator’s involvement can prove invaluable in preventing the design team from making assumptions which are later proven wrong. It opens the door for resource bartering, as well as instigating changes to accommodate resource restrictions. This is especially true regarding hardware, software and vendor products, and it also allows for staff reassignments in a non-disruptive fashion because necessary changes can be discovered and scheduled well in advance to when the changes have to occur.
Strenuously avoid the politics that so characterize project approval, resource allocation, scheduling and rollout. Emphasize what’s best for the organization, and gain management support via briefings and periodic updates emphasizing backlog management’s simplification of the development cycle and use examples to prove it. Discuss the valuable store of planning, forecasting and recruitment data that’s been built. Politics won’t disappear, but they can be minimized, especially if the backlog administrator is a good negotiator.
Backlog Management Reaps Big Benefits
I’ve worked in situations like the one where “a body is a body” and backlog management was performed on whim and guesswork, a disastrous game of blindly shuffling resources between projects. The result was a plethora of delays and programs riddled with errors, which destroyed IT’s reputation. I also had a major contract with a client to convert their claims system from vendor code to CICS and Db2. They objected to the allocation of significant time to learn the vendor code, but the client’s COBOL code was intertwined with it, so I stood firm. From my experience, working with unfamiliar code is 3-5x worse in productivity, and had I not held firm I shudder to think of the outcome. Taking time to develop the necessary expertise saved the day, proof that matching the right resource with the right project prevails. It also evades a lot of hostility, mistakes, delays and wasted time.