Unfortunately, that usually doesn’t work well with software development. When developers work long hours for weeks at a time, they burn out and write sloppy code. That leads to more bugs, which slows development, resulting in a delayed schedule, greater expense, and a low-quality result. Not only do you fail to achieve the desired time and cost-savings, but also you get to take the blame for missing the impossible deadlines.
Executive support is also critical for allowing a project to continue when it encounters unexpected setbacks such as missed deadlines or uncooperative software tools. In fact, unexpected setbacks are so common that you should expect some to occur, even if you don’t know what they will be. (Donald Rumsfeld would probably consider them “known unknowns.”)
Overall the executive champion provides the gravitas needed for the project to survive in the rough-and-tumble world of corporate politics. It’s a sad truth that different parts of a company don’t always have the same goals. (In management-speak, you might say the oars aren’t all pulling in the same direction.) The executive champion can head off attempts to cancel a project and transfer its resources to some other part of the company.
In cases like those, work can be somewhat unnerving, even if you do have strong executive support. I once worked on a project where both our executive champion and our arch nemesis were corporate vice presidents directing thousands of employees. At times I felt like a movie extra hoping Godzilla and Mothra wouldn’t step on us while they slugged it out over Japan. After two years of unflagging support by our champion, we finished the project and transferred it to another part of the company where it was quite successful for many years.
Executive champion duties include:
● Providing necessary resources such as budgets, hardware, and personnel
● Making “go/no-go” decisions and deciding when to cancel the project
● Giving guidance on high-level issues such as how the project fits into the company’s overall business strategy
● Helping navigate any administrative hurdles required by the company
● Defining the business case
● Working with users and other stakeholders to get buy-in
● Providing feedback to developers about implemented features
● Buffering the project from external distractions (such as the rest of the company)
● Refereeing between managers, users, developers, and others interested in the project
● Supporting the project team
● Staying out of the way
The last point deserves a little extra attention. Most executives are too busy to micromanage each of the projects they control, but this can sometimes be an issue, particularly if the executive champion is near the bottom of the corporate ladder. If you are an executive champion, monitor the project to make sure it’s headed in the right direction and that it’s meeting its deadlines and other goals, but try not to add extra work. As Tina Fey says in her book Bossypants, “In most cases being a good boss means hiring talented people and then getting out of their way.”
However, studies have shown that more engaged executives result in more successful projects, so don’t just get things started and then walk away.
PROJECT MANAGEMENT
A project manager is generally the highest-ranking member of the project team. Ideally, this person works with the team through all stages of development, starting with requirements gathering, moving through development and testing, and continuing until application rollout (and sometimes even beyond into future versions).
The project manager monitors the project’s progress to ensure that work is heading in the right direction at an acceptable pace and meets with customers and other stakeholders to verify that the finished product meets their requirements. If the development model allows changes, the project manager ensures that changes are made and tracked in an organized manner so that they don’t get lost and don’t overwhelm the rest of the team.
A project manager doesn’t necessarily need to be an expert in the users’ field or in programming. However, both of those skills can be extremely helpful because the project manager is often the main interface between the customers and the rest of the project team.
Project manager duties include:
● Helping define the project requirements
● Tracking project tasks
● Responding to unexpected problems
● Managing risk
● Keeping users (and the executive champion) up-to-date on the project’s progress
● Providing an interface between customers and developers
● Managing resources such as time, people, budget, hardware, and software tools
● Managing delivery
MYRIAD MANAGERS
There are a lot of kinds of project managers in addition to software project managers. Construction, architecture, engineering, and other fields have project managers. Just about any activity that involves more than a few people needs someone to perform project management duties, even if that person isn’t called a project manager.
This book even has a project manager extraordinaire, Adaobi Obi Tulton; although her title is project editor. She makes sure I’m turning chapters in on time, passes chapters to various technical and copy editors, and generally guides the book during its development.
In practice, some project managers are promoted from the developer ranks, so they often have good development skills but weak project management skills. They can give useful advice to other programmers about how a particular piece of code should be written or how one subsystem should interact with another. They can provide technical leadership, but they’re not always good at recognizing and handling scheduling problems when something goes wrong.
For that reason, some larger projects divide the project manager’s duties among two or more people. One project I worked on had a person dedicated to task tracking and making sure we kept to the schedule. She had training in project management but no programming experience. If something started to slip, she immediately jumped all over the issue, figured out how much delay was required, asked about contingencies in case the task couldn’t be finished, determined whether the delay would affect other tasks, and did all the nontechnical things a project manager must handle.
That person was called the “project manager,” in contrast with the other project manager who was called the “project manager.” It got a little confusing at times. Perhaps we should have called the task-tracking person the “developer babysitter” or the “border collie” because she gently guided us toward our goals by nipping at our heels. Often people call the other manager the “technical project manager”; although, that person may also handle nontechnical tasks such as interaction with customers and executives.
Meanwhile the “main” project manager was freed up to attack the problem from the development side. He could work with the developers to figure out what was wrong and how to fix it.
When I first encountered this set up, I thought it was kind of silly. Couldn’t a single project manager handle both technical and tracking tasks? In our project, the separation actually made things easier. This may not be the right approach for every project, particularly small ones, but it was useful in our case.
If you are a project manager or want to become one, you should do a lot more reading about specific tools and techniques that are useful for keeping a project on track.
Before moving on to other topics, however, I want to cover a few more project management issues in greater detail. The next three sections describe PERT charts, the critical path method (CPM), and Gantt charts. PERT charts and CPM are generally used together but are separated