My handlers tell me that the best way to kick off a shameless self promotion blog is to identify a problem that falls within the scope of the blog and then suggest one or more solutions.  So here it is.

Our beginnings never know our ends.  That is a particular problem with large development or implementation projects, and in particular lengthy ones.  In our contracts for such projects we define milestones and deliverables and use them as the measures of success or failure of the project – at least we should do that in most cases.  The problem we have is that usually it’s not clear at the beginning of a project how we should define those milestones and deliverables.  Car can be our defined deliverable, but what kind of car?

What to do?

The secret is in the approach we take in the contract process.  If we contract for the whole project, our contractual ship (continuing with our transportation theme) has sailed on day one.  As a result, good intentions notwithstanding, the vendor can deliver a car that does not fit in our garage.  That delivery to soon be followed by an invoice for services rendered; not satisfactorily, but within our deliverable definition – car.  Disappointment, shame and anger come next; as might litigation and unemployment.

Can this be avoided?  Maybe.

One approach is to enter into an agreement for a scoping phase and stop there.  The deliverable for the scoping phase would be a development or implementation plan that includes definitions of the needed milestones and deliverables for the full project.  No doubt those definitions will still be less than ideal, but we’ll create them with much better information.  After the scoping phase, armed with that better information, we can decide how to move forward.  By the way, this approach has a secondary benefit.  It gives us the opportunity to test drive the vendor and decide whether we can stand to be in the same room for the however-many-months of the full project.  Not a joke.

Another approach is to make a commitment for the full project, but break the project into phases.  For each phase we have cascading definitions of success and failure.  As in the model above, the project would likely start with a scoping phase.  The difference in this model is that the result of the scoping phase will not be a definition of final milestones and deliverables.  Instead, the deliverable for each phase will be a definition of milestones and deliverables for the next phase.

As the project moves forward in this model, we’ll have success and failure defined in light of the much better knowledge than in the simple model where there is no checkpoint between the beginning and the end of the project.  This is because we’ll be looking out at shorter time frames.

To optimize this model we will want to give ourselves the right to bail at the end of each phase – preferably with or without cause.  This gives us the ability to get out of projects that aren’t working.  We’ll be sure that our contract gives us full ownership of what was created up to the point of termination.  That way we could engage a different contractor to finish the project if that’s a viable option.

In summary then, we have identified three basic contracting models for large IT projects. We can dive in and at the outset define what we mean by success of the project.  Alternatively, we could take a first step, scope out the project a little (or a lot) and see where we want to go from there.  Or we could merge those options, making somewhat of a commitment to complete the project, but establishing multiple checkpoints at which we take stock and see how and if we want to keep going

 A principal factor in choosing amongst them will be the quality of the available information that we can use to define where we want to end up is.  In many cases the length of the project will be the factor that most affects our ability to have, at the time of contracting, satisfactory clarity about our desired outcome.  Of course that will be mixed with other considerations, and complexity can be one, but here the problem we have identified is the difficulty of predicting the future.  We haven’t solved the problem, but we have armed ourselves with some approaches to contracting that might mitigate the risks of our lack of fortune telling skills.