In a previous post I discussed how tracking business processes created or function points written can mislead. Business concepts (like business processes) can mean all things to all people because they’re too vague. A business process could be highly complex and take significant resources to implement or likewise, could be very simple and take a matter of days to write in software.

Function points are a little better in that most sensible project managers will attempt to define some “hard” characteristics. However, they’re still to vague because it is fundamentally a subjective exercise to determine the size any one function point.

My thought process orients around the essence of the project. Usually the ultimate goal is to deliver running, high quality software (i.e. code) that matches the needs of the business goals. Note that I deliberately used the term “business goals“. That will be a topic for another post, but needless to say it’s a very important point.

So, if the goal is well written code (see note * below), humming along nicely, meeting the goals of the business, what we need to measure is exactly that – well written code. Let’s tackle the “code” part first.

It’s the code, stupid

Project managers, systems architects and in fact all stakeholders must look at the code .. really! Think of it like a construction company. The directors will go a look at the work on the ground, check the quality of the poured concrete, look at the fit and finish of the work. Even the client is expected to participate. It’s called snagging, and it’s beyond me that it rarely (to the point of pretty much never) happens within IT projects. Most stakeholders ought to review samples, but project managers should expect to be fully involved in what the project is producing, in the same way as a construction project manager would.

Now, this needs some preparation and ideally it needs buy-in from stakeholders. They will need some preparation potentially in the form of training to be able to draw value from the process but let me assure you the pay back will be fantastic.

Well written?

The other critical metric is how well written the code is. Now there are many characteristics that can make the quality of code better or worse and there are many projects that fail to address this topic completely (I have first hand experience). The project must include work to establish the coding patterns, code structuring, reuse strategy and more within a set of coding standards that all project members understand and adhere to. The result, if well done will be a 10x productivity improvement and corresponding cost reduction to the project. Yes, it is THAT important!

*_{Some people will suggest that a business process is much more that just the software and therefore viewing the core deliverables of the project as being the software is at best incomplete. Well, over the years, large organizations and especially banks have move more and more towards decisions being codified in the software. The result is that the system typically IS the business process.}