As mentioned before: there is neither a worst nor best model. And there is also no generally good or bad approach to managing software development. Each model has its own advantages and disadvantages. And each model is meant to deal with (sometimes only slightly) different aspects than the other. Which of these models should be applied to a certain problem depends on the number of persons involved, the complexity of the software to be developed and the goals and even more aspects. The above introduction might already help evaluating the correct choices for each case. Most of the time the model is chosen indirectly by the way the software is supposed to be delivered and developed. If you really have the chance to choose a model for a future project, it might be best to not only think about the software lifecycle at hand but also about the tools, frameworks, and knowledge in need to support this kind of development.
Plan, Organize & Be Prepared
In today's competitive economic environment, companies succeed or fail based on their ability to bring quality products and services to market in a timely manner. It is the project manager's job to make sure that this happens.
Saturday, October 30, 2010
Thursday, September 30, 2010
Project Lifecycle
Like organic entities, projects have lifecycles. From a slow beginning they progress to a buildup of size, then peak, begin a decline & finally must be terminated. Also, like other organic entities, they resist termination!
A project starts with the customer’s need to improve, solve or fix a problem he faces in his domain. The idea or the need develops throughout the different project’s phases, known as the project lifecycle, till the project’s delivery.
Note: It is assumed that your project has already been selected, and that a Project Charter has been produced. A Project Charter is generally a document that provides a short description of the project and designates the Project Manager. Sometimes a commercial contract also leads to the initiation of project especially in firms specialized in providing professional/consulting services.
Project Initiation
During the initiating process, you will refine the project goals, review the expectations of all stakeholders, and determine assumptions and risks in the project. You will also start project team selection -- if the project team has been imposed, then you need to familiarize yourself with their skill set and understand their roles in the project. At the end of this phase you will produce a Statement of Work (SOW), which is a document that provides a description of the services or products that need to be produced by the project.
Project Planning
During the planning process, you will detail the project in terms of its outcome, team members’ roles and responsibilities, schedules, resources, scope and costs. At the end of this phase, you will produce a project management plan, which is a document that details how your project will be executed, monitored and controlled, and closed. Such a document also contains a refined project scope, and is used as the project baseline.
Project Execution
During the executing process, you apply your project management plan. In other words you direct your team so that it performs the work to produce the deliverables as detailed in the plan. The executing process also involves implementing approved changes and corrective actions.
Project Closure
During the closing process, you formally accept the deliverables and shut down the project or its phases. You will also review the project and its results with your team and other stakeholders of the project. At the end of the project you will produce a formal project closure document, and a project evaluation report.
Monitoring & Controlling
During the monitoring & controlling process, you supervise project activities to ensure that they do not deviate from the initial plan and scope. When this happens, you will use a change control procedure to approve and reject change requests, and update the project plan/scope accordingly. The monitoring & controlling phase also involves getting approval and signoff for project deliverables.
Tuesday, August 31, 2010
Project Initiation
With a good start & good high level planning one can consider half of the project complete
Your project has been selected, and you have been appointed as the Project Manager. You should now use the Project Charter or commercial contract, to get the wheels spinning in motion. At the minimum your Project Charter should:
- Designate you as the Project Manager with the authority to use resources to bring the project to completion -- this is formally done by the project sponsor/main stakeholders.
- Provide a short description of the result, outcome, product or services to be produced by the project.
- Refer to the commercial contract as the basis for initiating the project (if there is such a formal contract).
After having reviewed the Project Charter, do the following:
- Ask the Project Sponsor and main stakeholders to share with you any emails, letters, memos, project feasibility, meeting minutes, requirements or other documents related to the project.
- If a similar kind of project has already been completed, get your hands on all the documentation that was produced for that particular project. Set up a meeting with the project manager of that project to ask for advice.
SOW (Statement of Work)
The next thing that you want to do is start working on your Statement of Work (SOW), a crucial document that you will constantly update and use as a baseline for your project. Depending on the size and complexity of the project, and your knowledge about the subject matter, you will need to organize meetings with the stakeholders in order to refine the SOW and get it approved. A well-thought out SOW generally contains the following sections:
Executive Summary
Provides a short overview on the purpose of the project, its background, its scope and sometimes a high-level project plan.
Goals & Objectives
Describes the objectives of the project. The majority of project management literature recommends SMART objectives that are:
- Specific: your objectives must be clear so that if someone reads them, he or she can interpret them without ambiguity.
- Measurable: you should be able to measure whether you are meeting the objectives or not.
- Achievable: do not try to attempt more than you can.
- Realistic: do you have the resources to achieve your objective?
- Time-specific: specify when an objective will be attained (date)
Project goals example:
| Goal | Team Role |
|---|---|
| Satisfied customers | Product Manager |
| Delivery within project constraints | Program Management |
| Delivery to product specifications | Development |
| Release after addressing all issues | Testing |
| Enhanced user performance | User Education |
| Smooth deployment and ongoing management | Logistics Management |
Scope
Details the scope that you identified in the Executive Summary of the SOW. In this section, describe the work that will be done. Also, if required, explain what will not be done – this is especially useful to avoid confusion. Note that the Scope section is one of the most important sections of the SOW. Therefore, be very specific when writing it.
Deliverables
A list of the deliverables to be produced by the project. Describe each deliverable in an unambiguous manner that is understood by the team member responsible for it.
Examples of deliverables are:
- Project plan
- Requirements document
- Design document
- Source code
- Test plan
- Test cases
- Release notes
- User guides
Assumptions, Risks & Constraints
There might be a number of unknown issues while you are planning your project. For such issues you need to make assumptions, which constitute a risk. Typical project risks are associated with timeframes, and availability of resources (funding, project team members, supplies, etc.). Detail the identified risks in your project and include contingency plans for each risk. There might also be some constraints on the delivery of the project, e.g. time or cost constraints which are also part of the project’s assumptions and might be treated as risks.
Stakeholders
Definition
Any person or organization that is actively involved in a project, or whose interests may be positively or negatively affected by execution or completion of the project.
Stakeholders are an integral part of a project. They are the end-users or clients, the people from whom requirements will be drawn, the people who will influence the design and, ultimately, the people who will reap the benefits of your completed project.
Importance
One of the key elements of project stakeholder management is the use of influence (“the ability to affect the actions, beliefs and attitudes of other people”) to ensure that people give their support to our projects. It is extremely important to involve stakeholders in all phases of your project for two reasons:
- Firstly, experience shows that their involvement in the project significantly increases your chances of success by building in a self-correcting feedback loop
- Secondly, involving them in your project builds confidence in your product and will greatly ease its acceptance in your target audience.
Types
There are different types of stakeholders and each type should be handled differently:
- Executive: Executive stakeholders are the guys who pay the bills (Sponsors). Typically they are managers or
directors who are involved with commercial objectives for the project. They should restrict themselves to commercial considerations and be actively discouraged from being involved in technical design, their experience and skills are vastly different to that of 'typical' end-users.
- End-User: These are the guys that are going to use your product. No one knows more about what
the product is supposed to do when it hits their desks than they do. No one! Including you! You may think you know better but if you don't listen to them you're kidding yourself.
- Expert: Sometimes you need input from experts in other fields. People like graphic designers, support reps, sales or sometime lawyers and accountants.Project Managers must communicate with all Project Stakeholders to discover and manage their expectations before and during project execution, to avoid an otherwise successful project being perceived as a failure.
A list of all the stakeholders identified so far in the project. You may also want to detail roles of each stakeholder in this section. You should also make sure to clarify who will be responsible for the signoff of the different deliverables of the project.
| Tip: Get your SOW approved by the stakeholders. Once this is done, you will be ready to start planning. |