Project Management Resources & Links
Things to Keep In Mind as a Project Manager
Based on our experience, we suggest to keep a couple of things in mind when being a manager on a project:
1. Know the scope: The scope of the project needs to be outlined clearly and without any ambiguity. It is of the utmost importance that requirements are stated on one master document that all stakeholders sign off on.
2. Underpromise, overdeliver: Skillful client management is all about managing expectations. Don't promise miracles. Be as conservative and as careful as possible when making certain commitments towards the client. When you think something can be done within 1 month conservatively, tell the client it should be done within 2 months, then blow him away by delivering a thoroughly tested deliverable in 1.5 months.
3. No definite due dates: Try to refrain from promising delivery on firm deadlines. Instead of "timeline", "...will be done by...", use terms like "preliminary timeline", "...should be done by...". the reason why 92% of all IT projects are late is because project managers lock themselves into unreasonable timeline.
4. First requirements, then timeline: Before you provide any timeline, the requirements need to be defined thoroughly. Don't be afraid to object timelines that have been pre-determined because some senior manager felt like he knew when the project could be completed before clarifying the scope.
5. Take the red pill: This is taken from the movie "Matrix". In other words, don't fall prey to the illusion that everything is running smoothly. This will never be the case. The good project manager identifies an upcoming problem and nips it in the bud as soon as possible. The longer you wait the more severe the problem will grow.
6. KISS (Keep It Simple Stupid): Don't make it unnecessarily hard on yourself. Keep the initial scope of projects as simple as possible. There will always be time for extensions and modifications later on.
Proper Billing Procedure
We experienced with quite a few billing procedures for our software development project. We figured out that in a consulting business a proper billing procedure is a major success factor, the importance of which is not to be underestimated.
We used to take the following approach:
- Client pays 1/3 of the overall project sum as a retainer, the next third upon completion of 60% of the project, and the remaining amount upon project completion.
This procedure caused major problems: When exactly are 60% completed? When do WE consider 60% completed, when does the CLIENT think so? What about work completed inbetween those marks?
Over time we made an effort to change this procedure and this is what we do now:
- Client pays 1/3 upfront, additional items will be invoiced for as additional work gets completed.
Now this may sound ridiculously easy and minor. However, it has improved our cash flow significantly and has been very conducive to more predictability and certainty. This is because we did no longer need to worry about vague percentages or 100% completion that much. Invoices would be sent out upon completion of specific items and not only upon completion of a certain number of items. It enabled us to achieve a quicker turnaround between completion of items and money in the bank.
Make Assumptions
No client explains a project with 100% precision. There are always open issues that need to be clarified. Clarifying them all during the bidding process is impossible.
If the client is not clear in his specifications, make assumptions, and most importantly STATE your assumptions in your preliminary proposal and have the client ACCEPT them. If he does not then at least you know and you can revise them.
This will make a huge difference. If you submit a proposal without stating assumptions chances are that the client has had different assumptions than you and you are locking yourslef into an arrangement where you have to deliver something that you did not anticipate. This is a recipe for project failure.
Stated assumptions will significantly reduce the project risk and ensure that you know what you are bidding for. Assumptions are like safety hooks during an otherwise risky climb. They are like a magic formula against project failure due to unanticipated expectations. They allow you to change your pricing and your estimates as soon as it becomes obvious that they were incorrect.
Assumptions are a "must have" and a "must state" for every decent project manager.
Functional Requirements
In their book, 37 Signals claim that it is completely futile, yes even counterproductive to write functional requirements specifications. (http://gettingreal.37signals.com/ch11_Theres_Noth ing_Functional_about_a_Functional_Spec.php)
Now this may very well be true if you are an entrepreneur developing a web based software to sell on the web.
However, if you are a contractor who has to develop multiple custom applications for different companies, and who has to deal with all issues that ensue (billing, add-ons, scope) accurate functional requirements are an indispensable tool.
Their merit is manifold:
- they ensure that you don't commit to something that you can't deliver
- they force your client to be precise and think everything through
- they clarify what you have to do but more importantly what you don't have to do
- hence, they enable you to charge the client for additional features he requests and ensure that you company or you don't get burned
We started developing custom software without functional requirements and slowly progressed toward a process where we require software requirements specifications (SRS) for every project.
Suffice it to say that we went from chaos, poor financial performance, liability projects, burned resources, frustrated clients, frustrated project managers and a high degree of uncertainty (also called risk) to order, sound cash flow, clearly structured projects, fully billable resources, happy clients, motivated project managers and low risk.
Using standard software requirements specifications (SRS) has turned our business around. They can't be that bad after all.
Written by Nima Mahdjour of ProjectCenter
ProjectsCenter was founded in 2003 in San Francisco, California by an elaborate group of silicon valley software consultants who were and are all sharing one vision: Offering organizations and teams increased efficiency and higher project ROI by providing them with high-quality project management tools.
|