October 2005

Software Project Management (for Non-Project Managers)
by Kim Wasson, IvyBay Consulting

Project management sometimes seems like an unnecessary set of complicated processes, particularly for small companies.Many companies get their products out the door without any real structure other than a feature list and a ship date. So why bother with project management? 

Why

Every software company needs to know at all times where it is in any development cycle. For each project you need to understand, set and communicate priorities for products, features, cost, quality and schedule in order to make rational decisions. Without this understanding you will be forced into ad-hoc decision-making, which generally only takes into account the most immediate alternatives, ignoring other important factors.

Typically, decisions and trade-offs based on project status need to be made quickly as well as accurately. For this to happen, project status needs to be well and easily understood.

Also, it's vitally important to recognize when resources—people, equipment and budget—need to be shifted in order to keep a project on track. Without an adequate fix on the 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's not necessary to hire a project manager, use Microsoft Project or implement a complex project-management system. The keys are planning, communication and follow-through.

Planning

Involve as many team members as practical in each step of the project. This way the extended team gains a more thorough understanding of any issues; more creative ideas are generated and the team buys into the results.

• Understand the parameters and trade-offs of the project. Determine goals for the traditional "four dials"—features/functionality, schedule, cost/resources and quality. Typically you can only set two of these. If you try to fix all four, you will lose both agility and the ability to make trade-offs. At least one factor will suffer, but it will happen by default, without the chance to make a choice. Set goals for all four factors, but recognize and communicate their relative priorities.

• Define project completion in terms of schedule and/or features. (If you're using agile practice, this is determined for each iteration, but you should still define minimum ship goals for the product.) These goals can change if market conditions change, but you need a starting point.

• Break the project down into the smallest pieces that make sense. The biggest manageable tasks are at the feature level. If possible, break them down into the module level for development, the test run for QA and the chapter for documentation.  However, don't break things down just for the sake of breaking them down. That will cause unnecessary work.

• Once you have broken the project 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 this is the case; take a best guess and create a task to generate a better estimate when conditions are correct.

• If any tasks are interdependent—one has to be done before another can be started or two must start together or finish together—write these dependencies down and track them.

• Create a schedule based on the estimates, taking the dependencies into account.

• Build contingency time into the schedule. Focus on the scheduled completion date, but remember that the contingency can be used if needed. In the unlikely case that the contingency isn't used, the product can ship early or 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 you have enough people with the right skills to complete the project. Consider the first week or two of task assignments fixed and understand that assignment for later tasks will probably shift as they get closer. The unexpected will happen and you need the ability to react.

Communication

• The easiest and most effective way to communicate the project schedule is to put it on a reserved whiteboard in a public place. This provides 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 the week. Post it or send it out daily to remind your team. Be sure to note completed tasks. (We all need our accomplishments to be recognized, and this is an easy and effective way to build your team.) The list will also make it obvious when tasks are not completed on schedule, allowing you to shift resources.

• Whenever any change or decision is made, email the information to the extended team to keep everyone up to date and to receive timely feedback.

• Keep a running list of issues and decisions. Sometimes issues can't be resolved until later, and sometimes issues will take some time to resolve. Keep the entire list available, 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.

• Update the whiteboard at least weekly. If the schedule goes past the end date or into the contingency time, adjust the four dials. If you gain or lose resources, update the schedule.

• Have a meeting at least once a week in the vicinity of the whiteboard to discuss the schedule, problems and victories. This is an excellent time to review the rolling week schedule, update the plan and revise the whiteboard schedule.

• And have a party when the project is complete. Celebrating victories is key to good project management.

©2005 Kim Wasson. All rights reserved.