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

1. 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?

2. Does it facilitate administrative duties by integrating key project information? Examples of commonly integrated elements include:

   • Timeline

   • Action items

   • Issues

   • Risks

   • Status reporting

3. 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.)

4. Does it create network diagrams?

5. Does it do top-down and bottom-up estimating?

6. 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.

7. 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).

8. 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.

• Project Manager. With the previous two roles defined, the project manager doesn't have to develop or maintain tools and processes, become an expert user of tools, maintain detailed project data, or watch for low-level problems. She should be examining the environment external to the project (to ensure that the project remains aligned with core business objectives), facilitating the resolution of conflicts and issues (identified by the program analyst), managing communication with key stakeholders, performing other duties described in Chapter 5, and generally guiding the team and project forward.

Agile Strategy

Break up your project management duties into three distinct roles—the process developer, the program analyst, and the project manager—to both facilitate the operation of your project infrastructure and motivate your PM team.