Some software project managers (PM) do not know how to develop a project plan. They do not even plan but only use the schedules given to them by customers. They do not develop vision for the project or estimate the project efforts. Their logic is requirements always change, why bother to plan something that will change? They do not understand the purpose or the benefits of a project plan.
A project plan is a document used to communicate information between the project manager to the project team and the customer.
The first step in developing a project plan is to set the direction for the project. When the project starts, the team does not know what to do; they need a “Compass” to guide them. The project vision is the compass that points them to the direction set by the project manager. The vision explains to them what success would be; what kind of problems the project will solve for the customer; what are the goals and objectives and what the customer’s expectation are. The vision keeps the team’s effort aligned with customer requirements and project objectives.
The second step is to describe the problems that the project is intended to solve. Team members need to understand the problems, as well as what a successful solution could be. They need to know about the customers and users. A project may have one single customer or multiple customers with different requirements. In this case, the team needs to know how to balance several different requirements and still meet customers’ needs.
The third step is to describe the software product. The best way to do this is to use the Context Diagram, in which project manager defines how the software interacts with customers or users, and how information flows in and out of the system. This Diagram will give the team an overview of the software.
The fourth step is to describe the high level functions of the software product. The project manager should describe each function based on customer’s requirements. If the software is large and complex, some functions can be divided into sub-functions for easy description. It is important that project manager validates these functional requirements with customers to ensure that they are exactly what the customers need.
The fifth step is to break down these functional requirements into smaller tasks (Work Breakdown Structure) and list these tasks so team members can see all the tasks that they must do. Since requirements often change because of additional needs, new information, or sometime customers decide to change the requirements. These changes will affect everything in the project. Therefore the project needs to have a plan to ensure that only the correct requirements are implemented. By keeping a current list of all the tasks, team members know which task has been changed or modified, and how they impact their works. When project begins, team members do not know all information that customer want so they rely mostly on this list of tasks. It is important to keep this list up to date based on additional information. The project plan will define how to deal with changes, how changes will be reviewed, and how the list of tasks will be updated to ensure that the project will meet the needs of customers.
The sixth step is to define the roles, responsibilities of each team member and assigns them to tasks based on their skills and experiences. By identify team members by skills, project managers will know which skills are available for which task and what skills are needed. Project manager can identify team members that have these skills, if not he may have to hire additional people with specific skills to complete the project. This is an important because some project managers often rely on the number of people available for the project instead of their skills. They staff projects by number of people needed rather than skills needed. For example, if the project needs 10 people then they hire 10 people regardless of their skills. This is one of the reasons that many project failed. Experienced project managers always staff project based on skills not on number of people needed. In this step, project manager also identifies hardware, software, and equipments needed for the project and how they will be obtained.
The seventh step is to estimate the efforts needed to complete these tasks. It is recommended that project manager works with team members that have been assigned tasks to come up with an estimate for their works. Project manager must take each task and put them into the order which they will be done then summarize them into an overall estimated time required to complete all tasks. Using this information, project manager can negotiate with customers on project schedule. A project schedule should be based on an agreement based on customer’s expected schedule and the summary of the estimated time needed to complete all tasks. The project manager can ask for changing schedule if there is significant different in scheduled time and estimated time; or more people; or reduce functionality. Once the negotiation is complete, project manager will update the list of tasks and assign a date to the start and completion of each of the tasks as well as update the project’s budget (Money allocated to the project).
The eight step is to plan for product quality. Quality does not just happen; it needs to be built in. The project manager needs to identify the quality standard to which the project will be measured and how team members will measure them. For example, quality can be defined as meeting all customer requirements; having fewer defects (No more than 1 defect per ten thousand lines of code); meeting cost and schedule etc. Quality must be defined clearly and reviewed with both customers and senior managers to ensure that the project is producing a quality product.
The ninth step is to managing risks. Since not everything that happens within software project is known. Things may happen as a surprise because they cannot be predicted. These uncertain things are risks and they must be managed. The project manager needs to identify project risks, their possibility of occurrence, how to mitigate them and how to communicate them to team members, if they happen.
The tenth step is to define project documentation. Depending on the complexity and customer requirements, a project may be required to provide supporting documentation as part of the project deliverables. Documentation includes user manuals, online help, installation guides, etc.
----------------------------------------
Prof. Vu
Carnegie Mellon University
source: http://www.segvn.org/forum/mvnforum/viewthread_thread,1388
Its really informative, the facts and the other features mentioned are quite considerable and to the point, would be better idea to look for more of these kind to have better results.
ReplyDeleteField Service Management Software