Wrapping up the project
Wrap up and Celebrate are the 2 big items left.
It is time to install the product at your client's site and provide them with all the documentation and training that they need.
You must gain the client's acceptance of the deliverable. If the acceptance criteria were well defined in the first phase of the project, all should be well.
Take some time to write up an internal report on the project - something that is meant only for your company. This report should cover the overall success of the project, strengths and weaknesses, lessons learnt, recommendations for next time, and reusable components that can be used for other projects.
Finally, CELEBRATE! This is a very important and often overlooked step. Your team has worked hard, and their efforts need to be recognized. They also need a small breather before they jump into their next tasks. The celebration can be a party away from the company's premises, gift certificates to movies/restaurants etc. This sort of team-building is important, and will boost employee morale and productivity.
There are three important aspects of project management that we haven't covered in as much detail as they deserve: Giving Presentations; Boosting Employee Morale and Productivity; and Time Management. But those are topics for another day and page. :)
Good luck!!
Wednesday, May 30, 2007
Monitoring Progress
Monitoring progress
Well, you've successfully started off the project. But you can't sit back and relax now. You’ve got to continuously monitor progress.
Institute regular progress reports; weekly works well. Tell your team that the report does not have to be formal or pretty; just a clear concise listing of salient points will do. If someone misses a progress report, don't overlook it, but quickly ensure that the importance of the report is made clear to that person.
Hold regular status meetings at predetermined days/times to allow people to be prepared. Catch deviations from the plan or schedule early, and take corrective action. Keep the client informed about changes.
If the client asks for extra items, negotiate either extra time or extra resources (and therefore money) to meet the increased expectations. But do try to throw in a few small freebies - extra items that you will not charge the client extra for, in terms of time or money.
Tip: Always send out an agenda well before any meeting. This minimizes wasted time and there won't be any "I will have to look that up and get back to you."
Reminder: If there is someone at these meetings who is unfocussed and rambling, it falls upon you to firmly bring the meeting back to focus without disrespecting the rambler.
Always give people credit for their ideas. Never put down any idea as "stupid".
Your team is looking to you for leadership. Try to gain consensus for your idea rather than forcing it on people.
Your team is looking to you for inspiration. If you want your employees to be conscientious in their work, provide the example by being conscientious yourself.
Provide constant feedback to your team members. Give feedback soon after the corresponding achievement or failure. Feedback should be specific, not general and vague. I have seen announcements made like this: "A big thank you to Chris for working hard to make this project a success." What about Dave and Ellen who also worked hard and did their part? A better announcement would have been: "Thanks to everyone who worked hard on this project and made it a success. A special thank you to Chris who stayed late last Friday to fix a critical problem." Since Chris is being thanked for a very specific thing, Dave and Ellen cannot take offence.
Institute and mandate use of a change control system like CVS to maintain progressive versions of your software and even documentation. Have an organized QA procedure to ensure the quality of your product.
Tip: Don't forget to assign somebody to do documentation like User Manuals. Make sure the documentation person is involved in the project from beginning to end so that he/she understands all the context.
Finally! It's time to wrap up the project. Ice-cream for everyone? Good idea, but all in good time.
Well, you've successfully started off the project. But you can't sit back and relax now. You’ve got to continuously monitor progress.
Institute regular progress reports; weekly works well. Tell your team that the report does not have to be formal or pretty; just a clear concise listing of salient points will do. If someone misses a progress report, don't overlook it, but quickly ensure that the importance of the report is made clear to that person.
Hold regular status meetings at predetermined days/times to allow people to be prepared. Catch deviations from the plan or schedule early, and take corrective action. Keep the client informed about changes.
If the client asks for extra items, negotiate either extra time or extra resources (and therefore money) to meet the increased expectations. But do try to throw in a few small freebies - extra items that you will not charge the client extra for, in terms of time or money.
Tip: Always send out an agenda well before any meeting. This minimizes wasted time and there won't be any "I will have to look that up and get back to you."
Reminder: If there is someone at these meetings who is unfocussed and rambling, it falls upon you to firmly bring the meeting back to focus without disrespecting the rambler.
Always give people credit for their ideas. Never put down any idea as "stupid".
Your team is looking to you for leadership. Try to gain consensus for your idea rather than forcing it on people.
Your team is looking to you for inspiration. If you want your employees to be conscientious in their work, provide the example by being conscientious yourself.
Provide constant feedback to your team members. Give feedback soon after the corresponding achievement or failure. Feedback should be specific, not general and vague. I have seen announcements made like this: "A big thank you to Chris for working hard to make this project a success." What about Dave and Ellen who also worked hard and did their part? A better announcement would have been: "Thanks to everyone who worked hard on this project and made it a success. A special thank you to Chris who stayed late last Friday to fix a critical problem." Since Chris is being thanked for a very specific thing, Dave and Ellen cannot take offence.
Institute and mandate use of a change control system like CVS to maintain progressive versions of your software and even documentation. Have an organized QA procedure to ensure the quality of your product.
Tip: Don't forget to assign somebody to do documentation like User Manuals. Make sure the documentation person is involved in the project from beginning to end so that he/she understands all the context.
Finally! It's time to wrap up the project. Ice-cream for everyone? Good idea, but all in good time.
Getting the project off to a start
Getting the project off to a start
Now that you've created the project plan, it is an exciting time. You get to kick off your project! You must first recruit a team. Ideally, choose people who have a history of collaborating well together. Pick a good mix of people - some senior and some junior.
Remember that your goals are to give the senior members leadership experience, and also to get the junior members to better their technical expertise.
Clearly establish rules up-front. You must make sure the team members know whom to approach for small technical issues, big roadblocks, and technical help.
If a senior team member is responsible for a junior member's work, make sure that you give the senior member the authority to meet that responsibility. Responsibility and authority must always go together. If Bob is responsible for a task's success, but Ivan who is implementing that task is not accountable to Bob, then Bob will be ineffective in ensuring the success of the task.
Tip: Try to ensure that for any key piece of functionality, 2 people are in the know. If you rely on only one person, and that person is unavailable due to some unforeseen reason, the project will be in trouble.
Make sure everyone is aware of the schedule for the project as well as intermediate milestones. It is important to get everyone on the same page as early as possible so that they can plan their execution.
Go easy on the documentation here. Some of the major/complex tasks should have their design documented, but not every single task. UML can be useful in this kind of documentation, but don't go overboard and try to document detailed class diagrams for every single class.
(This is just duplicating the implementation.) Instead, if there is a complicated control flow or multithreaded functionality, draw sequence diagrams to make it clear.
Now that you've created the project plan, it is an exciting time. You get to kick off your project! You must first recruit a team. Ideally, choose people who have a history of collaborating well together. Pick a good mix of people - some senior and some junior.
Remember that your goals are to give the senior members leadership experience, and also to get the junior members to better their technical expertise.
Clearly establish rules up-front. You must make sure the team members know whom to approach for small technical issues, big roadblocks, and technical help.
If a senior team member is responsible for a junior member's work, make sure that you give the senior member the authority to meet that responsibility. Responsibility and authority must always go together. If Bob is responsible for a task's success, but Ivan who is implementing that task is not accountable to Bob, then Bob will be ineffective in ensuring the success of the task.
Tip: Try to ensure that for any key piece of functionality, 2 people are in the know. If you rely on only one person, and that person is unavailable due to some unforeseen reason, the project will be in trouble.
Make sure everyone is aware of the schedule for the project as well as intermediate milestones. It is important to get everyone on the same page as early as possible so that they can plan their execution.
Go easy on the documentation here. Some of the major/complex tasks should have their design documented, but not every single task. UML can be useful in this kind of documentation, but don't go overboard and try to document detailed class diagrams for every single class.
(This is just duplicating the implementation.) Instead, if there is a complicated control flow or multithreaded functionality, draw sequence diagrams to make it clear.
Planning The Project
Planning the Project
Break the entire project up into individual activities. The completion of each activity should be measurable. As far as possible, each activity should also be assignable as an independent entity to an implementer/developer. This way, delays in one activity will not hold up other independent activities.
Estimate how long it will take to complete each activity. This is partly an art. As I gained more experience and became more familiar with the working styles of my team members, I got better at estimating duration. A general rule of thumb is to calculate an optimistic duration (if everything goes exactly right), a pessimistic duration (team member falls sick, unexpected technical hurdle comes up) and a likely duration (most things go right, but may run into a few hitches).
Then compute the estimated duration as (Optimistic + Pessimistic + 4*Likely)/6. That way, you're giving more weight to the likely scenario, but keeping options open for a very good or a very bad scenario. If you underestimate the duration, you will not be able to deliver on time, which hurts the reputation of the company. If you overestimate the duration, you are basically cutting out additional features that could have been added to make the product more competitive in the market.
Assign resource types to each activity. Note that at this stage, you are not assigning specific people to the activities; you are assigning only a resource type, e.g. Senior Database Developer, Java Developer, Senior UI Developer. However, it helps to have specific people in mind. That way, you know what other projects they are working on, how much time they can devote to this activity, and when they will be on vacation or leave.
Keeping track of activities, their durations, dependencies and resource assignments can quickly become complicated. Use a tool like a Gantt chart to make sense of the complexity. A product like Microsoft Project allows you to create Gantt charts showing dependencies and durations of activities. You can also mark milestones. You can change starting dates or resources around and watch the effect on the milestone/deliverable dates.
Tip: Don't break activities up into minute overly-detailed tasks at this time. Things are bound to change, and overly-detailed Gantt charts can be extremely hard to modify and keep up-to-date. Think in terms of big modules and keep activities few and simple.
Tip: Remember holidays (like Memorial Day, Thanksgiving) and vacation days of team members while making the Gantt chart. Also account for some slack in the work during the week around Christmas and New Year. Microsoft Project will let you set certain days as non-working days and will compute deliverable dates accordingly.
This is the time to write a project plan or a high-level architecture and design document. Be sure to provide sufficient background in this document so that the actual implementers (development team) have enough information to complete their respective tasks. You must research alternatives and document clearly what the alternatives were, and why a particular alternative was picked. Otherwise, much later, you will have to face long discussions where the same alternatives and decisions are discussed again.
Reminder: Keep the architecture and design document in a shared directory, make sure everyone relevant can access it with the appropriate privileges (read-write or read-only), keep the updated revision history in the document itself, and email back and forth only pointers to the document and not the document itself.
UML is useful for this kind of documentation. Draw use case diagrams and deployment diagrams at this stage, coupled with perhaps a few sequence diagrams to clarify complex control flow. Microsoft Visio is one of the tools that allows you to draw UML diagrams electronically, though they can also be hand-drawn.
Reminder: Electronic (as opposed to hand-drawn) documents are easier to modify, copy and keep track of.
Tip: Throughout the architecture and design process, keep in the back of your mind that your company will benefit if components of the product can be reused for other projects/clients. Keep copyright laws in mind, however.
Alright! It's time to start executing all that well-planned material.
Break the entire project up into individual activities. The completion of each activity should be measurable. As far as possible, each activity should also be assignable as an independent entity to an implementer/developer. This way, delays in one activity will not hold up other independent activities.
Estimate how long it will take to complete each activity. This is partly an art. As I gained more experience and became more familiar with the working styles of my team members, I got better at estimating duration. A general rule of thumb is to calculate an optimistic duration (if everything goes exactly right), a pessimistic duration (team member falls sick, unexpected technical hurdle comes up) and a likely duration (most things go right, but may run into a few hitches).
Then compute the estimated duration as (Optimistic + Pessimistic + 4*Likely)/6. That way, you're giving more weight to the likely scenario, but keeping options open for a very good or a very bad scenario. If you underestimate the duration, you will not be able to deliver on time, which hurts the reputation of the company. If you overestimate the duration, you are basically cutting out additional features that could have been added to make the product more competitive in the market.
Assign resource types to each activity. Note that at this stage, you are not assigning specific people to the activities; you are assigning only a resource type, e.g. Senior Database Developer, Java Developer, Senior UI Developer. However, it helps to have specific people in mind. That way, you know what other projects they are working on, how much time they can devote to this activity, and when they will be on vacation or leave.
Keeping track of activities, their durations, dependencies and resource assignments can quickly become complicated. Use a tool like a Gantt chart to make sense of the complexity. A product like Microsoft Project allows you to create Gantt charts showing dependencies and durations of activities. You can also mark milestones. You can change starting dates or resources around and watch the effect on the milestone/deliverable dates.
Tip: Don't break activities up into minute overly-detailed tasks at this time. Things are bound to change, and overly-detailed Gantt charts can be extremely hard to modify and keep up-to-date. Think in terms of big modules and keep activities few and simple.
Tip: Remember holidays (like Memorial Day, Thanksgiving) and vacation days of team members while making the Gantt chart. Also account for some slack in the work during the week around Christmas and New Year. Microsoft Project will let you set certain days as non-working days and will compute deliverable dates accordingly.
This is the time to write a project plan or a high-level architecture and design document. Be sure to provide sufficient background in this document so that the actual implementers (development team) have enough information to complete their respective tasks. You must research alternatives and document clearly what the alternatives were, and why a particular alternative was picked. Otherwise, much later, you will have to face long discussions where the same alternatives and decisions are discussed again.
Reminder: Keep the architecture and design document in a shared directory, make sure everyone relevant can access it with the appropriate privileges (read-write or read-only), keep the updated revision history in the document itself, and email back and forth only pointers to the document and not the document itself.
UML is useful for this kind of documentation. Draw use case diagrams and deployment diagrams at this stage, coupled with perhaps a few sequence diagrams to clarify complex control flow. Microsoft Visio is one of the tools that allows you to draw UML diagrams electronically, though they can also be hand-drawn.
Reminder: Electronic (as opposed to hand-drawn) documents are easier to modify, copy and keep track of.
Tip: Throughout the architecture and design process, keep in the back of your mind that your company will benefit if components of the product can be reused for other projects/clients. Keep copyright laws in mind, however.
Alright! It's time to start executing all that well-planned material.
Defining the scope project
Defining the project scope
The first thing to realize is that the client often does not know what he/she wants. Never start a project without first agreeing on clear requirements. This is what worked for me. I would start with a simple Project Overview and discuss it verbally with the client. Then I would go back and write up a detailed Functional Spec containing a Requirements Matrix. (I describe each of these documents below.)
The more effort you spend here upfront, the less crises you will face in later stages of the project when things are harder or impossible to change.
A Project Overview looks like this:
Problem description
1. Goal - 1 or 2 measurable broad goals, achievable in the timeframe
2. Objectives - a small list of specific sub-goals
3. Success criteria - how will we know when we're done?
4. Assumptions - ensure that there are no surprises later
5. Risks and alternative plan - if something goes wrong, can we change direction?
Each of these sections should be described in plain English, with as few technical details as possible. One or two paragraphs per section usually suffice. The aim is to arrive at an agreement on the broad objectives of the project. Discuss the Project Overview verbally, in a face-to-face meeting with the client's managers, if possible. This is the first test of your communication skills - both written and oral.
The first thing to realize is that the client often does not know what he/she wants. Never start a project without first agreeing on clear requirements. This is what worked for me. I would start with a simple Project Overview and discuss it verbally with the client. Then I would go back and write up a detailed Functional Spec containing a Requirements Matrix. (I describe each of these documents below.)
The more effort you spend here upfront, the less crises you will face in later stages of the project when things are harder or impossible to change.
A Project Overview looks like this:
Problem description
1. Goal - 1 or 2 measurable broad goals, achievable in the timeframe
2. Objectives - a small list of specific sub-goals
3. Success criteria - how will we know when we're done?
4. Assumptions - ensure that there are no surprises later
5. Risks and alternative plan - if something goes wrong, can we change direction?
Each of these sections should be described in plain English, with as few technical details as possible. One or two paragraphs per section usually suffice. The aim is to arrive at an agreement on the broad objectives of the project. Discuss the Project Overview verbally, in a face-to-face meeting with the client's managers, if possible. This is the first test of your communication skills - both written and oral.
E. Team-building skills
E. Team-building skills
This is an often-neglected area, forgotten in all the excitement of project deadlines. But the effort spent motivating a team to perform to the best of its ability is worth its weight in gold. Four easy points to remember are: reward achievements, provide feedback, recognize strengths and provide challenges.
Instead of talking in generalities, let us follow the lifecycle of a project step by step, and see how these skills come into play.
A Project Manager is involved in all of the following 5 phases of a project.
Phase 1: Scoping the project
Phase 2: Planning the project
Phase 3: Launching the plan
Phase 4: Monitoring progress
Phase 5: Wrapping up the project
This is an often-neglected area, forgotten in all the excitement of project deadlines. But the effort spent motivating a team to perform to the best of its ability is worth its weight in gold. Four easy points to remember are: reward achievements, provide feedback, recognize strengths and provide challenges.
Instead of talking in generalities, let us follow the lifecycle of a project step by step, and see how these skills come into play.
A Project Manager is involved in all of the following 5 phases of a project.
Phase 1: Scoping the project
Phase 2: Planning the project
Phase 3: Launching the plan
Phase 4: Monitoring progress
Phase 5: Wrapping up the project
D. Leadership skills
D. Leadership skills
This one is not easy. It is tricky to get your team to go with your idea without making them feel that the idea is being thrust on them. The team looks to the Project Manager to provide direction and vision. To be able to do that, I had to work constantly towards enhancing my knowledge - breadth of knowledge is very important, but depth is important too - superficial knowledge fools no one. A manager must earn the respect of his/her team, and the best way to do that is to lead by example.
This one is not easy. It is tricky to get your team to go with your idea without making them feel that the idea is being thrust on them. The team looks to the Project Manager to provide direction and vision. To be able to do that, I had to work constantly towards enhancing my knowledge - breadth of knowledge is very important, but depth is important too - superficial knowledge fools no one. A manager must earn the respect of his/her team, and the best way to do that is to lead by example.
Subscribe to:
Posts (Atom)