Project Management for Non-Project Managers

What

Every software company needs to be able to tell where they are in a development cycle. Understanding progress and being able to make decisions quickly and accurately are key to bringing a product to market in the right timeframe at the right level of quality. For small projects or small teams, it is often possible to accomplish this type of tracking without a professional project manager and with very simple tools.

Why

For each project (and amongst projects) the company needs to understand, set, and communicate priorities of products, features, cost, quality, and schedule. Without this understanding, no foundation exists upon which to make decisions – the only alternative is ad-hoc decision-making, which generally does not take into account any but the most immediate factors and alternatives.

Progress on a given project must be understood and communicated in order to understand when decisions and trade-offs must be made. Typically, decisions and trade-offs based on project status need to be made quickly as well as accurately; project status needs to be well and easily understood to make these decisions and trade-offs effectively. There should be no surprises – slips should happen only with warning.

Finally, it’s vitally important to understand when a shift in resources – people, equipment, etc. – needs to be made in order to keep a project on track. Without adequate project status, it can be extremely difficult to recognize this need in time to respond quickly and effectively.

How

For relatively straightforward projects with minimal interdependencies, it is not necessary to acquire the services of a project manager, to use Microsoft Project, or to implement many of the other complexities of professional project management. The keys are planning, communication, and follow-through.

Planning

• Involve as many team members as practical in each step of the project. In this way, there will be a more thorough understanding of any issues, more creative ideas will be generated throughout the process, and the team will buy into the results. Be sure to include the extended team – representatives from QA, Support, Tech Pubs, and Product Management as well as development, CM, database, etc.
• Understand the parameters and trade-offs of the project. The first step is to understand and set the traditional ‘4 dials’: features/functionality, schedule, cost/resources, and quality. Typically, only two of these dials can be set. If an attempt is made to fix all four, agility and the ability to make trade-offs will be lost. At least one of the four factors will suffer, but it will happen by default - without the chance to make choice. The factor that most often suffers is quality. Goals should be set for all four factors, but the relative priority of each must be recognized.
• Know when the project will be done. Set the project parameters. If using agile practices, for instance, this will be determined for each iteration, but the product ship should still have minimum ship goals defined. These goals can change if and when market conditions change, but the company should know its goals.
• Break the project down into the smallest pieces that make sense. The biggest tasks that are at all manageable are at the feature level; if possible, break down into the module level for development, the test run for QA, and the chapter for documentation. Track at the most detailed level that makes sense, but don’t break things down just for the sake of breaking them down – that will cause unnecessary work in tracking. A good rule of thumb is that no single task should be more than one week in duration at the absolute maximum – if there is a single task that takes more than a week, try to break it into smaller pieces.
• Once the project is broken down, estimate the time it will take to complete each task. Sometimes this will be very imprecise – some tasks just can’t be well-defined until others are complete. Recognize that this is the case, take a best guess, and create a task to generate a better estimate when conditions are correct.
• If there are any dependencies between tasks – one has to be done before another can be started, or two must start together or finish together – capture the dependencies.
• Create a schedule based on the estimates, taking the dependencies into account.
• Build some contingency into the schedule. For the remainder of the project focus on the scheduled completion date, but know that contingency can be used if needed. In the unlikely case that the contingency isn’t used, the product can ship early or can receive more extensive testing.
• Assign resources for any tasks that require special skills.
• Make a first-pass attempt to assign the remainder of the tasks to determine whether the company has enough people with the right skills to complete the project. Assuming that the people are available, consider the first week or two of task assignments fixed and understand that assignment for later tasks will probably move as they get closer. This is a good thing – it provides flexibility in the schedule. The unexpected will happen and the company needs the ability to react.

Communication

• The easiest and most effective way to communicate the project schedule is to put it on a reserved whiteboard where everyone can see it. (Agile practices often use posted index cards.) This makes for an easy way to update the schedule. Everyone can see it, and people can mark their own tasks complete.
• Keep a rolling list of tasks due for each week. Post it or send it out daily to remind folks – that way when someone finishes something they’ll communicate it. This will also make clear when tasks are not completed on schedule, allowing management to shift resources if possible. When the list is sent, be sure to note when tasks are completed. We all need recognition of our accomplishments, and this is an easy and effective way to help build your team.
• If any changes or decisions are made, send the information out to the entire extended team in email. Feedback will be generated immediately so adjustments can be made.
• Keep a running list of issues and decisions. Sometimes issues will turn up that can’t be resolved until later in the project, sometimes issues will take some time to resolve. Keep the entire list, including the resolution to past issues. Never revisit decisions unless new information comes to light – the running list of issues will help remind the team of decisions made previously.

Follow-Through

• Update the whiteboard at least weekly. If the schedule starts going past the end date- or into the contingency time - make the appropriate decisions to adjust the four ‘dials’. If you gain or lose resources, the schedule will also have to be updated.
• Have a meeting at least once a week somewhere in the vicinity of the whiteboard to communicate schedule, problems, and victories among the team. This is an excellent time to review the rolling week schedule, make any updates to the plan, and revise the whiteboard schedule.
• Be sure to have a party when the project is complete. Celebrating victories is key to good project management.