Project Measurement and Control

How horrible are people at managing projects ? Create a plan, let it gather some dust while you do something different , then bin it. This is one of the biggest problems today in IT.

One thing I want to do is to derive some risk management best practices for the types of projects we tend to do in Capital Markets, based on some of the experience out in the marketplace for agile development and other alternate approaches. The other area I want to evolve is the role and experience of our project leads in these projects -- are they domain experts, converted PMs, upgraded BAs, maturing techies ..... ? Stay tuned on this one.

From a vendor's perspective, I have found that a formalized status meeting of both sides is key -- bi-weekly being a good balance between not intruding on people's time and staying on top of things. The focus is not so much on measurement and control (M&C), but on risk and issue management, as well as general performance feedback. A couple of main reasons, I see, for this: a) it is the client PM's job to do the M&C as well as our own team lead (in terms of his team's tasks), b) I have to trust my guys and not to micro-manage them (not my style anyway), and c) it is the big ticket items, politics and barriers that will screw the project, and not so much the minor implementation or functional details.

That said, too many times project-based consultants get treated like the staff-supplementation folks (and that's not just our people that feel this), resulting in the client PMs (micro) managing the tasks of our folks. This is an uphill battle, but a fight we need to stick to in order to ensure we don't get sucked down a rathole and away from the project in hand.