tomport

Sailing in the right direction

Large software projects and how to ensure success.

Keep a constant eye on “the big picture”, not doing so is like taking your eye of the ball in a football game – guaranteed failure.

The lessons behind this single, overarching consideration come from seeing project after project driven down into detail at the earliest opportunity. I attribute this to discomfort with open questions, discomfort with ambiguity and also the personality traits that are essential for project managers to succeed at the later stages of exciting the project – I.e. attention to detail, a strong focus on delivering against a set task and a discomfort will undefined problems.  

Are you an executive with a big project in mind? Maybe it’s already a business imperative? How do you start? These are the sort of questions that are so often gotten wrong. Here are some tips:

  • Don’t assign a project manager when you’re still shaping the project
  • Keep and open mind and consider as many strategic options as possible
  • Get the right “startup team” in place

To expand on each point above:

Project managers are generally not the right people to shape a project’s overall direction, what’s needed at this stage is a skilled individual with strategic and wide ranging business experience but also with the detailed delivery experience that’s gained through living through large projects.

Changing direction on a large project, once set, is terribly difficult if not impossible. It’s essential that radically different strategic options are explored and understood before money is spent on any one direction. Believe me, this is perhaps the single most important measure on any large project. The difference between strategic options can be orders of magnitude!

These initial steps require deep skills, wide experience and people willing to work with ambiguity and an open mind. Often not the attributes you need to run a project day to day, so put in place a project startup team that have the right characteristics to shape and can guide the running project to success.

This isn’t is a comprehensive guide to project management, however it will help anyone facing the challenge of working within a similar project, at least as a reminder of things that need to be attended to.

These notes are drawn directly from my experience working at a senior level within large scale software projects – typically in the $100’s of millions of dollar/euro budget range. During a period of 30 years, I’ve seen both successes and (rather more) failures; I have observed and captured a good picture of where and how things come unstitched, why they come unstitched and what steps can be taken to reduce the chances of failures. I have attempted to capture those lessons here.

tomport

It’s all about the code!

mid journey generated data centre

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.

tomport

Metrics? What are those.

In my last post I listed the 5 most important (in my humble opinion) “hidden” factors which are likely to cause project failure. I suspect it’s an unusual list and I also suspect number 5 on that list is one of the most misunderstood.

Misunderstood because no project manager is ever going to say they have no metrics. Project managers always have metrics. Many many metrics. So I hear you saying “what’s the problem, my PM’s have loads of metrics, they report on them endlessly”.

Well, the point is that many exclude those that are most important and include metrics which mislead.

Consider this reasonable sounding list of metrics:

  1. Business processes to be replaced
  2. Function points to support those business processes
  3. Cost of implementing each function point
  4. Dependencies between the functions and the business processes

Well, they look super don’t they? No.

This list ignores measures of what’s really driving cost and productivity – useful code written and the “power” of that code. A business process could require 10 lines or 1 million lines of code, likewise a function point. So you have 1000 business processes? Great, but these metrics offer no information on how much work is required.

Key to modern software production is to carefully structure and construct such that a single software module can be used in many different business processes and many different function. It’s no coincidence that modern programming languages like Rust or Swift have focused on providing tools to generalize code writing, for example “generic functions” and extendable types.

In a future posting (don’t worry, it’ll be quite soon) I’ll delve into some metrics which more accurately measure project cost, progress and value.

tomport

Hidden factors: why IT projects fail.

It’s always been a fascination for me. Some figure close to 80% of IT projects fall short of their original goal, many or even the majority by a huge margin. By fall short I mean some end result like costs doubling, often alongside timescales also doubling. In the worst case, millions are spent and the result never even goes live – I have personally come across such a project recently, having been asked to review it close to go live date.

And yet most of the underlying causes of project failure are easy to identify.

So, here are my top 5 causes of project failure:

  1. Weak project structure and relationship to the business
  2. Inexperienced project management
  3. Poor role and responsibility discipline
  4. Inability or ignorance of the relationships with implementation contractor
  5. Absence of meaningful project metrics

I’d draw your eye to an interesting point:

Project success or failure isn’t primarily driven by the technology choices themselves. Instead, it’s largely driven by what is put around the technology.

I’d like to expand on these points over coming weeks. Watch this space.