Section 10.3. Manage the Organization


10.3. Manage the Organization

An important part of the project manager's job is managing upward in the organization. The way that you interact with your organization's senior management can make or break your projects. When you make changes for the better, you are changing their organization, and, whether or not you are successful, your boss will want to be involved.

10.3.1. Senior Managers See Software Projects as a Cost Burden

Many project managers face an uphill battle when interacting with their organizations' senior management. They find that senior managers have an increasingly antagonistic view of their software projects. The senior managers only see the cost of the development, and often fail to see how the software projects help the organization. These problems are compounded when projects come in late, or do not fill the needs of the stakeholders.

In the mid 1990s, Mary Lacity and Rudy Hirscheim published a study of 14 Fortune 500 companies in which they interviewed over 60 senior managers about their attitudes toward IT projects. They found that the overwhelming majority of them thought of their IT departments as a "cost burden" that steadily increases their costs without adding to the profitability of the company. This attitude is pervasive not just in large companies, but in organizations of all types and sizes.

Unfortunately, most project managers cannot just sit down with their organization's senior managers and explain the value of their projects. They must show over time that there is a real reason that each project is developed, and that each project's benefits justify the cost of development.

Many of the project management practices in Part I are aimed at communicating this. The vision and scope document is the project manager's first opportunity to ensure that each project is developed based on real and specific needs, and that the features of the software are aimed at fulfilling those needs. The vision and scope document and the project plan communicate the real costs and benefits of development to senior managers in terms that they understand. And a change control process ensures that the managers are kept apprised of all changes to the project, and that those changes are worth their costs.

A project is successful if its costs are justified by its benefits. Establishing a track record of successful projects is the most effective way for a project manager to reverse dangerous attitudes in senior management.

10.3.2. Show Senior Managers the Impact of Their Decisions

The first step in working with senior managers is to know what a best-case scenario looks like. In good organizations, decisions are based on objective standards and metrics that were developed in advance to determine the health of the application. The goals of the project are decided from the outset, and a successful project will have met those goals. Project decisionsapproval of schedules, deadlines, budgets, and resourcesare made by a single person or a group of people who make those decisions based on objective evidence.

Unfortunately, in small- to mid-sized companies, this is not usually the case. Decisions are frequently made based on gut feelings instead of objective analysis. The people in charge of project decisions are not necessarily experienced in working with software projectsin many cases, this may be the first time they have encountered software projects. Even in software companies, a small or young company may be run by a manager or management team with industry, business, or organizational experiencebut without much experience managing software projects. While gut decisions can be successful, they will often lead to serious project problems.

It's true that project decisions based on gut instincts are often correct. If that were not the case, people would never get into the habit of making gut decisions in the first place. But the fact is, most small businesses are run entirely on gut instincts. And if you have a small product with a small and well-understood user base, those gut decisions make intuitive sense to anyone who understands both the product and the clients. That usually includes the upper management of such a company. As a result, many small businesses have successfully built and sold software products using mostly gut instincts to govern their decisions.

One typical example of project management by gut instinct is release readiness. The typical reasoning sounds like this: "We've tested the product longer than we did for the last release, and we have not encountered any major problems. So let's release it!" In contrast, a release readiness process that was based on objective facts would require that a certain percentage of the code base is covered by the tests, and that the number of defects that are discovered falls below a certain threshold (based on the size of the application). For example, the product might only be considered releasable if at least 70% of the code has been executed under test, if no critical defects are found, and if there are fewer than 3 medium-priority and 10 low-priority defects per 10,000 lines of code. Keep in mind that the exact same testing activities could be performed in both cases; it's just that in the second case, everyone has already agreed that if these objective and measurable criteria are not met, more testing is needed.

In a small company, the senior managers are happy if they are making more money this year than last year. Most of the time, they don't try to figure out why that happened. They know that what they are doing is working, and there's no need to question it. This attitude is very common, and you must recognize its relevance to your projects.

Some senior managers feel that they have navigated more difficult problems than whether or not to put the code under source control or add another round of testing. These things seem like details to them, and they don't feel that they need to read a book to figure them out. To someone with this attitude, the very fact that you are concerned about these "details" makes you seem like an alarmistyou are up in arms about something that they consider very minor. Or, even worse, they feel that they have done a fine job of building a software organization, and are insulted that you think that you can make it better by introducing changes.

If an organization is in the software business, the people running that organization need to understand the details of making software. Making those decisions is uncomfortable for a senior manager with little software experience: it is hard to make sound decisions about building software when one has only a simple, high-level view of software design, programming, and testing.

One common senior-management response to this problem is to attempt to delegateprobably to you, since you have read a book about it and seem to know what you are talking about. Unfortunately, this is a shallow commitment that can cause its own problems. If your boss does not understand the goals of the improvements you want to make or the reasons behind them, he will not make consistent decisions. The actions that you take in implementing new practices on your project will impact other people: they will create additional work for some of them, and many will perceive that you are taking away some of their power, flexibility, or freedom. And, in some poorly run software organizations, there may be people assigned to software tasks who are not very good at those tasks; they might prefer not to have their work measured or analyzed. If they see you as an interloper, they will complain to your boss. If he does not understand why you are doing what you are doing, all he will see is conflictconflict that you created with the changes that you made. Since he did not take the time to understand the benefits of your actions, he will simply blame you for making changes and causing conflict. Your improvement effort will grind to a halt.

The solutionand it is not an easy oneis that upper management must be better educated about the details of your project. The person who has the authority to tell you (and everyone else on your level) to undertake a project should understand the purpose behind every step in the software process. This means more than just understanding that software needs to be designed, developed, and tested. He needs to know why the software is being developed that way.

It means that if, for example, you are trying to implement inspections, then the senior manager must understand what an inspection is, what is being inspected, what kinds of defects it will find, why those defects are there, who needs to attend the inspection meetings, and what will happen if the inspection is skippedand he needs to understand this before the inspections are implemented. He must be sold on the idea. If he does not agree that this is the most efficient and effective way to develop software, he will fold the first time someone decides that inspections are "bureaucratic," unnecessary, or somehow getting in her way. It is only with some genuine understanding of the changes you want to make that he will be able to make a real commitment to them.

The process of educating your organization's senior management must go both ways. You need to put time and effort into understanding the goals and needs of the organization and its senior managers. The easiest way to do this is to call a meeting with them. The purpose of this meeting is to write down their goals and needs. These should be written in their language (e.g., improving profits, increasing the customer base, reducing support calls, etc.). Be sure to meet with them periodically in order to keep this list up-to-date. You should be able to use it to show how your improvements will help them meet these goals.

10.3.3. Don't Confuse Flexibility with Always Saying Yes

There are many situations when a project manager disagrees with the people around her. Sometimes a project is going off track or experiencing problems. Other times, people disagree with her approach to a project. It is important to be flexible in these situations. But sometimes it is hard to figure out just what it means to be flexible. Flexibility might mean making sure that everyone understands that the project is in a difficult situation, and agrees on the course that it will take. But it might also mean listening to the dissenting opinions and making changes to the way the project is being managed. Flexibility should never mean having to cave in to unreasonable requests.

10.3.3.1. Don't agree to an unrealistic schedule

When somebody asks you to do something, it is natural to want to satisfy themespecially if that person is above you in your organization. Many project managers operate in a climate of constant pressure from above, and they want to alleviate that pressure by being positive and agreeable.

Some senior managers think that all dates are negotiable, and that teams can always be pressured into releasing software earliereven if the team's projected date is based on realistic estimates and solid project planning. Sometimes upper managers will just challenge the team's opinion because they believe that anything can be done sooner if the team works harder. Unfortunately, just increasing the pressure on the team is a poor motivator. It makes people feel as though their opinions have been second-guessed, that their expertise is not valued, and that their work is not respected. Nevertheless, it's a common situation.

For example, consider a project in which the senior manager in charge has set a deadline, but it is clear to the project manager that this deadline is too aggressive and the team will never meet it. If she simply goes to the manager and tells him that the project is headed for failure, he will probably just think that she is not being a "team player". He will probably put a great deal of pressure on her to just accept his deadline and work the team harder, possibly forcing them to put in overtime in order to meet the goal. He would consider that being "flexible." But in reality, that's a recipe for team demotivation, and probably disaster. The senior manager's "solution" does not solve the problems that are keeping the project from delivering at that time. In fact, simply agreeing to the deadline is actually being inflexible, in that it ignores the reality of the situation and fails to present alternatives that might actually help the team meet the deadline (or, at least, satisfy the organization's needs that motivated the decision to impose the deadline).

Creating transparency and gathering consensus are the most effective ways to address this. When a project slips, the project manager needs to diagnose where the planning went wrong or what risk was not previously considered. Hopefully, she has done enough planning (see Chapter 2) that she has real evidence that the project will not meet the deadline. In this case, true flexibility would involve presenting the senior manager with options, such as doing a phased release, scaling back the features to be developed, or adding resources.

10.3.3.2. Change your approach when necessary

Sometimes a project manager is faced with a project that is coming in early. The schedule was the result of a difficult negotiation, and moving the date earlier means giving up the hard-won project time. It seems counterintuitive to move the deadline up and give up the extra padding. But there are cases when this is necessary.

One of the most common situations that results in decreasing the schedule is when a programmer discovers a shortcut. For example, a project may have gone through a solid estimation process, and a project plan was created when one of the assumptions for the estimates was that a certain component would have to be built from the ground up. For example, if a programmer discovers that this component can be replaced with one purchased off the shelf, this reduces the effort required to build the software.

Many project managers would happily sweep this under the rug and keep that extra schedule time as a buffer against future schedule slips. This feels like "flexibility" to the project manager, because it keeps her options open in the future.

The temptation to keep the buffer in the schedule must be resisted. Just as the overly aggressive deadline had to be resisted with transparency and honesty, the project plan must be kept honest in this case as well. The reason this is the truly flexible option is that the extra effort can then be reused by the organization, either to extend the current project or to apply it to a future one. Keeping that effort on the current project schedule denies it to the organization and limits its ability to develop other projects.

10.3.3.3. Don't confuse "easy to describe" with "easy to implement"

Many changes are very easy to describe in words. Yet most programmers can tell horror stories about being asked for a "tiny change" that turned out to require an enormous amount of effort. A manager asking for an easy-to-describe change will often assume that any project manager who balks at immediately implementing the change is being inflexible.

It is a common myth that having a software processthat is, deciding on how you are going to build the software before you actually build itis inflexible. The feeling is that requiring that the software be planned and designed before it is built will prevent programmers from just jumping in and making any small changes that are needed by the organization. This is one of the most common complaints that project managers hear when trying to implement a reasonable planning process.

In fact, it is the planning process itself that provides the most opportunity for flexibility. It's very difficult to figure out which changes are easily contained, and which ones will have much larger consequences. Sometimes a change that seems tiny will require a large coding effort, while a change that seems large from a user perspective is actually relatively minor to implement but could have a lot of testing implications. The only way to get an accurate picture is by engaging the team and having them estimate the impact of the changepreferably using a change control process (see Chapter 6). Controlling the changes will give the organization the most flexibility.



Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net