Section 10.2. Do Everything Out in the Open


10.2. Do Everything Out in the Open

It is a very frustrating situation for a project manager when he makes a decision or takes an action, and then finds that a colleague or senior manager disagrees with him for seemingly no reason at all. Many times, these disagreements arise from a lack of communication . If everyone in your organization has constant access to everything that you and your team produce, the mystery behind why you make your decisions goes away. People may still disagree with you, but at least they will be disagreeing with your ideas and not simply because they felt like they were kept out of the loop.

It's not possible to tell everyone everything all of the time. But if it is known to the organization that a project manager is sharing his project information, and all of his colleagues know where they can find that information, they are much less likely to feel like information is being hidden from them.

Whether you are interacting with your team or with your organization's management, it is important that everything that you do is transparent. This means that when you create a document, hold a meeting of interest to others, or make an important project decision, you should share all of the information produced and used with everyone involved.

10.2.1. Publish Your Work Products

All work products should be kept in a public repository. This could be a shared folder or directory, a version control system, a Wiki or other sort of web interface, a knowledge base, or some other system for information storage. This ensures transparency for both team members and the organization's management.

When each person on the team knows that the work she is doing can be read and used by all other team members, she will feel much more accountable for her work than if she were doing the same thing in private. In general, people tend to create more readable documents, build more maintainable designs, and write more readable code if they know it will be shared with others.

Managers also benefit from transparency of work products. For example, if a product ships and a client encounters a defect, a client support manager can consult the test plan for the part of the product in which the defect was found. He might want to see the defects reported in the defect tracking system, or check the specification for the feature to verify that it is indeed a defect and not a misunderstood feature. Publishing the work products allows everyone in the organization to use them as reference materials.

Your senior managers will especially benefit from transparency. If it is your responsibility to specifically summarize and report every aspect of every product, it is highly likely that you will, on occasion, leave out an important item. However, if your boss is used to looking at the project documents himself, there is no chance that you will leave him in the dark. This will help build trust between you, and will also help discover any impending problems.

Another problem that is avoided through work product transparency is information hoarding. Sometimes an insecure person feels that he needs to keep certain aspects of his day-to-day work secret from the rest of his organizationeven his manager. This helps him feel more important to the organization, since any time anyone needs access to that information, they must go through him. In some cases, it even (unfairly) provides job security: if he's the only person who has maintained that particular work product, it is much harder to fire him if he's doing a poor job. That secrecy also makes it difficult to judge how poor a job he's doing.

10.2.2. Make Decisions Based on Known Guidelines

If you do things the same way every time, the people who work with you will come to understand the reasoning behind your decisions. They will feel much more comfortable with you than if you make decisions in a less predictable manner. One way to help others understand your perspective, and avoid surprising them, is to publish the standards by which you manage.

There are several ways that guidelines can help make your decisions more predictable:

  • Use published standards documents to help others understand the way certain roles must be filled. For example, a standard for interacting with a version control system might require that each programmer verify that the code builds without compilation errors before it is checked in. Programming standards may include naming conventions for variables or files. A testing standard might specify that a test plan must be executed by somebody other than the person who wrote it. Acceptance criteria and release readiness criteria are useful standards to help the organization make unbiased and objective decisions about when to release the software into test or to the general public. In addition, inspection checklists are also a kind of standards document.

  • Documents should be based on templates when possible. This ensures that all of the information that is needed in the document is included, and that important omissions are noted by the person writing the document. For example, a template might require that a vision and scope document always have a section for future releases. For projects that are only expected to have a single release, this section will contain "N/A" or a placeholder. This will prevent the reader from wondering whether the author meant that there would be a single release, or whether it was an oversight.

  • Process documents ensure that each project is done using a repeatable process. That ensures that the same activities for the current project are done in the same order as previous projects. This helps each person on the project understand how their work fits into the big picture, and reassures them that they are doing the right tasks. Process documents also give them the ability to compare the team's performance from project to project, to determine whether the organization is improving over time. The scripts used throughout this book are examples of process documents.

  • Use performance plans to set expectations for individual team members. Each person in the organization should have her performance measured against a written standard, and she should be given an active role in helping to define that standard. This helps her gauge how she is performing and provides a positive environment for her manager to help fix performance problems and reward good work.



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