Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
1. How do I figure how much the project will cost?
In principal the cost of a project consists of the cost of all the resources and material needed. If you have one person work for a month for $3,000, add the cost of his or her workspace and other tools, and you would have the total cost of your project. It's as simple as that.
Difficulty lies within estimating the cost of a project up front; how much do you EXPECT it to cost? Basically you start out by listing all the work that has to be done (you can use a Work Breakdown Structure for that), estimate how long each step will take, and multiply that with the associated price of a resource. Software estimation is a fine art with some very useful techniques. Most of the time, it is OK to have rough estimates for the cost of the project. You don't have to try to get it down to the last two digits. Because your estimates have a margin of error any way, you can omit the finer details.
This would take care of the software construction. However, in your WBS you can also include training, installation, and even replacements for the people that conduct the tests (in case these tests are done by the end users). Put in housing, equipment and other stuff that people need to do their work and you are good to go.
Finally, you can also do a project with fixed cost: you just say it will cost $10,000 and see what you can deliver for that amount. In this case the reasoning is the same, however in reverse order.
2. How do I write a good project report?
For a good project report always use the language of your target audience. If your audience consists of certified Project Management Professionals (PMPs) you can use project management lingo; if it consists of a 65 year old shopkeeper, use terms he is used to. Assuming we are talking about a normal progress report you will create once a week or two weeks, you can stick to the following basic outline:
What did you have planned?What did you actually do?
What were the reasons behind deviations from the plan?
What have you planned for the next period?
What are your risks?
How do you counter those risks?
Indicate status about budget, schedule, quality and scope
That should cover it. But just keep in mind; write only relevant stuff in the language of your audience. Don't write large risk management chapters just to impress people. They will not read it -- period.
This was first published in May 2007