Teams are usually aligned with major projects; however, in an agile environment, a working team can also be a small group that is quickly brought together to solve a particular issue and later disbanded, a functional group working on process improvement activities within that function, or a management team dealing with a competitive threat. The efforts of these teams, while not formally defined as a “project”, can be captured and analyzed along with other PM efforts as part of the infrastructure.
The operational PM infrastructure is like a machine that takes in real-time project data from many sources, analyzes it, and then creates valuable information for the project teams to use in making decisions and running the projects. The inputs to this machine may be documents, online tools, e-mails, or voice mails and may include meeting minutes, decisions, issues, action items, risks, status reports, and anything else related to the project. While this will definitely take some effort on the part of the team members, the system should be designed to make input of the data as painless as possible. The basic value proposition of the PM infrastructure should be that the effort required to provide input to the machine (i.e., the infrastructure) will pay off many times in the form of robust information on which project and business decisions can be based.
Agile Infrastructure As a Means to Reduce Administrative Headaches
A final benefit of a well-designed operational infrastructure is that it can greatly facilitate the administrative parts of managing a project. This benefit is largely related to efficiency, but can also be somewhat of a motivator for the project manager. Much of successful project management is about paying close attention to detail around administrative tasks, such as documentation, status reporting, action item follow-up, activity synchronization, issue management, and project timeline updating. Project managers sometimes employ as many as three to four separate software packages to handle administrative functions. The challenge is to keep all of the information integrated and up-to-date. While they are not impossible tasks, these cumbersome administrative duties are relatively distasteful to most professionals, who would rather focus on higher-level contributions.
Furthermore, these administrative tasks tend to be proportional to the level of uncertainty, making them increasingly more time-consuming in the agile project. Issues may arise, the project may fall behind schedule, action items are assigned, or something outside the project may occur that will affect the team. Very soon the administrative effort to keep all of these events organized and prioritized becomes daunting. This is especially true if you are using multiple software tools that are only integrated through your own transcription or by using copy and-paste techniques. In this scenario, it is not unrealistic for the project manager to get sucked further into a black hole of administrative activities, which in turn can be quite demotivating.
However, both the administrative and motivational issues can be addressed by a robust operational infrastructure. For example, let’s say that on route to a major milestone, the team encounters a technical obstacle. To overcome this challenge, resources are pulled from other current activities, effectively stopping them, and multiple subteams are formed to attack the problem. These subteams start work immediately on brainstorming an approach to the problem, but not necessarily a detailed schedule. Nonetheless, many action items get assigned and the team members disperse to start work. This should be an exciting time for the project manager, during which she adds significant value to the project. However, all too often the project manager spends her time running around documenting and following up on these action items and creating timelines and status reports, all the while hoping that there is some coordination of the major efforts. With an operational infrastructure in place, these administrative tasks would be handled much more efficiently, thus freeing up the project manager to get out in front of the team to direct traffic, which is where she prefers to be in the first place.
Implementing Your Agile Infrastructure
Many organizations tend to build their project management infrastructure around available software rather than first figuring out their processes manually. This often comes down to economics, since it is generally very expensive to have custom software written around your unique processes. However, when you are developing an agile infrastructure, this can be a dangerous trap because many of the popular off-the-shelf tools have been developed and optimized around the classic PM environment, so they emphasize front-end activities, like planning and budgeting, instead of execution. Newer tools are more configurable and include functions that automate the execution of projects. However, these enterprise-level tools tend to be prohibitively expensive for smaller agile businesses. The list below outlines some basic considerations when selecting PM software. I prefer tools that do a good job of covering the basics while leaving out the bells and whistles, which are often costly, have few actual applications, and make the tools difficult to use. Ease of use is one of those characteristics that doesn’t get much attention when evaluating software, yet is incredibly important for the simple reason that if the software is hard to use, it won’t get used.
Agile Strategy Select software tools that cover the basics well, leave out the bells and whistles, and are easy to use.
Since agile project management concepts are still in their infancy, it may make more sense to manually design an infrastructure tailored to your specific needs and ease into integrated software solutions as ones that meet your needs and budget become available. While, as a rule, I believe that working with multiple distinct software packages is cumbersome and inefficient, this may be the best option for developing your initial operational infrastructure. This approach also gives you the opportunity to work the bugs out of your processes before investing in more expensive, integrated systems. At the end of this chapter, you’ll find a high-level example of what an operational infrastructure may look like. Hopefully, it will spark some thoughts on how you might implement your own infrastructure manually (using multiple general-purpose and disconnected software programs, as opposed to specialized and integrated PM software solutions).
Considerations for Selecting PM Software Tools for the Agile Project Environment
Does the software help with execution-stage activities, such as action item and issue management, as well as planning-stage activities like Gantt chart creation?
Does it facilitate administrative duties by integrating key project information? Examples of commonly integrated elements include:
Timeline
Action items
Issues
Risks
Status reporting
Does it create reports in a format that can be viewed with standard office tools? (Reports generated in standard formats are easier to share and therefore facilitate communications.)
Does it create network diagrams?
Does it do top-down and bottom-up estimating?
Does it have powerful features that you’ll probably never use? You’ll have to pay for these features, even if they are not relevant to your needs.
Is the cost of the software in line with your budget? Consider that you may need to purchase several copies or a site license (for project managers and team members).
Is it easy to use? If the program is hard to use, it won’t get used.
Manual implementation of an operational infrastructure is a viable, cost-effective, and logical way to get started in this area. However, there are a few keys to success in a manual implementation and they revolve around the project management organization itself—specifically, how PM duties are divided up. Most companies don’t differentiate how duties are split among different PM roles. They have only a single set of duties, which is “do everything”. They may have different levels of PM responsibility, such as junior or senior project manager, which is related to the importance or complexity of assignments, but the basic duties are the same.
The effective implementation of a manual operational infrastructure requires organizations to create three distinct PM roles that work together to increase the overall value of the project management office. These roles are:
Process Developer. This is the person who actually develops the detailed tools, processes, and templates, as well as designs how they will work together. The architecture at the end of this chapter, along with the workflows throughout the book, will give your process expert a start in this area. However, she will still want to do some customization for your unique project/business environment and, just as important, will need to maintain the infrastructure as it evolves.
Program Analyst. This person is an expert user of the tools and processes that make up the infrastructure. This individual is skilled in using the tools not only for routine tracking and maintenance tasks, but also for more crucial analysis tasks. Note that basic analysis tools should already be designed and built into the infrastructure’s tracking and reporting mechanisms. This role is especially valuable when there are multiple, related projects running independently. Ideally, a single program analyst will run the infrastructure for the whole organization and will support several project managers. Since the program analyst has the best view of the real-time project information coming in from the various projects, he is in the best position to identify and analyze potential interproject issues. The program analyst also creates various types of reports for communicating his analyses and other key project information to the project managers, team members, and other stakeholders in a timely fashion.