Envisioning

It's been a few days since my last post. Let me explain why: from time to time Objeq actually demands me to do some billable work ;-). It's funny but, as passionate as I am for VM architectures, low level design patterns, and down-to-earth coding, nowadays I usually get paid for determining the business value of a software project, doing high level project design, assessing risk and generally helping teams start a project on the right foot. What they call the envisioning phase in MSF.

I've been writing code for some 18 years now and still believe the most challenging (and fun!) part of a project is writing the code. Yet, there is that (perhaps) 20% of the efforts that must be used for finding out why we want to do the project and how we plan to accomplish it. And, as many of you, I feel wary of those dense methodologies that makes you fill reams and reams of paper just because they say so. That's one of the reasons I like MSF: it's almost as light as it gets. And most of it is common sense that rings true for developers and managers as well.

In the envisioning we finished just yesterday, it was particularly delightful to create the initial risk list for the project. The team began the exercise with some suspicion but as we started to articulate what could go wrong with the project, they soon realized they could actually help, with specific actions, to raise the success chance of the project. They also found a number of additional activities to be considered on the schedule and ended finding reasonable a delivery date that on principle they tought was unacceptably far. And, as so usually happens with this lucky guy, all I had to do is just sit and watch while they themselves allotted more time for completing the project.

By the way, in the unlikely event that someone around here happens to need a Spanish translation of the MSF Risk Management Discipline slides just drop me a line, I will be happy to comply.