Last post I described both the development/maintenance methodologyand the project management methodology. It is the planning of theproject where the two intersect.
The prime PM artifact for creating a plan is the Work BreakdownStructure (WBS), defining the tasks to be performed, dependenciesbetween tasks, the people assigned to the tasks, and the effort andelapsed time estimates for the tasks. This can take a lot effort tocreate from scratch but, most development methodologies are preciselythat; the set of tasks and such needed to produce the desireddeliverable. So, why not plunk that set of tasks into your project’sgant chart, assign some real people, and off you go.
The problem is, methodologies strive to include all the possibletasks you might need in a systems project, but they (the good ones,anyway) don’t mean to say that all those tasks are needed for everyproject; you are supposed to customize that set of tasks so that youend up with only the ones you really need.
The best methodologies even help you with this, offering customizedversions of their task set depending on the type of IT deliverable youare going to produce. I have seen this for Data Warehouse projects,then for Website Development projects, and then for whatever came next.Information Engineering once even came with a Maintenance Methodology,although it was less about tasks and more about setting up amaintenance organization structure. (I wish I still had that one.)
Within your set of tasks, however, you need to pick up on the onesthat actually deliver something useful, and weed out any “busy-work”tasks that don’t contribute to getting the project done. The onlydeliverable of real importance is the final product. If you could justwork immediately on creating that and produce a quality result, then alot of this methodology “stuff” would not be needed. However, we foundout early on in the IT discipline that you could produce something thisway, but quality was likely not going to be an attribute of the result.So, on came methodologies and the concept of the ‘intermediatedeliverable’.
Although most commonly associated with the methodology, the intermediate deliverables one usually sees in IT projects are:
• Scope Definition
• Requirements
• Design
• Code
• Executables
Methodologies may use different terminology, and most certainlybreak these down into subsets (like Functional versus Non-FunctionalRequirements). The key here is that things are delivered that can becommonly slotted into one of the above categories, and the real keyhere is that they should be something that another specialist will useas input to their assigned project tasks. Tasks that don’t deliversomething should be cut out of your task list, and even moreimportantly, tasks that deliver something nobody else uses should becut out too.
So, if you are starting a project following your standardmethodology, I recommend getting all potential team members together,especially those who don’t come on until later in the project, andreview what deliverables you might produce and determine if someonewill use them, during and after the project (don’t forget abouttraining or support deliverables). This will give a clear set ofdeliverable-dependencies, and one can define the project’s WBS aroundthose dependencies; then compare this to a previous project where thiswas not done, and you will find your new project looks simpler and mucheasier to manage.