Tuesday, July 18, 2006

Pragmatic Project Principles?

My latest project has some interesting challenges.  Firstly, like virtually all interesting projects the deadline is fairly determined.  It happens to be far away, which is good, but fixed nonetheless.  Next, the resources to meet the tasks are unfamiliar with the technologies we are using, they aren't formally trained in software engineering, and have existed in a culture of complacency for the last several years. Okay, so having resources that are barely competent and lazy is different but not insurmountable.  After all, the best solutions I've ever known have been created by lazy people to facilitate their laziness (and yes, I am known for being mayor of lazytown).  Lastly, it is run by formally trained, highly experienced consultants who have been thoroughly brainwashed and bamboozled into plan-driven methodologies (think waterfall approach and the like).

The main challenge with this is that plan-driven approaches revolve, by definition, around a detailed plan of tasks and schedule, hence the name.  Which works well in environments consisting of relatively known behaviors, requirements, and abilities.  For example, a team of consultants all similarly trained on a project with ample time to define and document the requirements in sufficient detail.  That would not be this project.

To embrace the uniqueness of the environment the approach followed must be capable of supporting the differing levels of resources and abilities, the ambiguous nature of the requirements, and a general resistance to behavioral change.  Simply put, when you have people whose performance you can't estimate, working on tasks that are not fully defined, you really won't have much of a plan to manage against.  And any plan you initially create will invariable fall apart under the speed of which changes are encountered. See Sun Tzu for details.

There are various techniques for operating under these types of conditions, after all we're not the first nor will we be the last to find ourselves in such tumultuous waters.  In following posts, I'll discuss some of these approaches which I have found to be especially effective.  They specifically impact the Document and Design phases of the 5-D Approach which I've discussed previously.

Post a Comment