Process Management

 

Traditional Project Management focuses on 3 aspects viz. Cost, Duration and Quality. These variables are all interdependent.

 

Here’s what I have gathered during the past years, when I was a Project Manager:

 

  1. Never start without a good understanding of the functional requirements. Technical requirements can follow, but not the functional. Squeeze out every ounce of information from the client on the functional aspect of the system.
  2. Know what the client wants, to as much detail as possible. I don’t mean that you have to go till the level of screen design, but apply the 80-20 rule here. Get to know that 20% of the system, which is 80% significant to the client.
  3. Gone are the days when we used to have so much of paperwork like a Project Initiation Note (PIN), Engagement Strategy etc. Some of us are working on Projects which have a deadline of 2 weeks. All you get to do is work extra time. But we come across nature’s bottleneck. – only 24 hrs in a day.
  4. Waterfall is out. Iterative is in. Keep requirements open ended, as I’m pretty sure that most of the times the client himself is unsure in some area(s). Plan out the iterations. At-least, a tentative one.
  5. Spend more time on Requirements and Design. The cost of messing up during these early stages can prove to be fatal. Remember a company like Microsoft spends collectively about 60% of it’s time in these 2 areas.
  6. Follow simplicity for estimation. For instance, don’t go for a FPA when you are doing short projects or KLOC if you using object oriented languages. Add to this the complexity that a RAD tool also brings in (the IDE). For internet projects, I go by what I call as the ‘Divide by 2’ estimate. Depending on the timeline, set up an atomic unit beyond which you will abstain from simplifying.
  7. Mirror the requirements and freeze them as early as possible. Remember the clock is ticking on. You want to get a sign off? Up to you.
  8. Allocate resources sparingly, use extra buffers of at-least 25% average over a task. Do not compromise this. This is your best hedge against a duration risk.
  9. Create / Hold only those documents which are essential. Like say a copy of the contract ,(which should cover Scope, SLA’s and Deliverable dates clearly (and of course the payment plan)), the project plan (typically a Word Document containing the original MPP),  Requirements Document (and FS / SRS or simply MOM’s) , Design Document (both application and DB), Standards and Practices Document, Quality Documents (like record of Peer Reviews, Code Walkthru, Test Plan),  Hardware/ Software and Deployment approach.
  10. Skip Config / Change / Risk Management for short projects. This doesn’t mean that you don’t follow these. It simply means that do not make any documents for the same. In fact you can also pass over some of the quality documents also given above. For projects > 45 days, be my guest.
  11. Planning is important, but too much of it will be a time guzzler. Focus more on execution, esp. for internet projects.
  12. The choice of languages / environment / H/W etc. is all pretty much in the open. For e.g. for small to medium scale projects, you can use .NET, while  bigger projects can go for JAVA. (complexity on a scale of 1-6, opt for the former. From 4-10, choose the latter. Complexity is measured in terms of number of pages, meta pages, the contents, active links and features required. For e.g: integrating a payment gateway is pretty straightforward, but if you want to interface with a German ITEK mainframe, that is going to be more complex)
  13. Update and track project plan on a daily basis. Microsoft Project is a great analysis tool, also. See for eg: that resources are not overloaded, task assignments are always interconnected logically and so on.
  14. The quality of deliverables is a suspect, wherever there is no process existing to take care of the undesired. Follow a process: mandatory, call it IPO, PDCA or whatever other models are out there. Let me repeat: Even if it is a small project, there clearly has to be a methodology (procedures) that all follow.
  15. Last but not the least, be aware of the team dynamics. Make corrections wherever necessary. Learn to anticipate a problem before it occurs. Sun Tzu in the Art of the War says ‘A war is won before it is fought’. Get used to this.

 

 

Rajesh Menon (Nickname Guru30)

 

e-mail:             rajesh.menon@guru-30.com

rajesh30menon@yahoo.com

 

Website:          www.guru-30.com

 

Tel:                  91-22-25890408

Mobile:            9867071790