This post is a continuation of  Keys to Project Success - Part 8

The Devil is in the Details

Years ago we had to implement some business functionality into a large trading and settlement system that was for tax reporting and withholding.  I met with the leader of the release team and his head designer for this new feature to review the design, as I knew if it wasn't done correctly, we’d be facing fines and a regulatory mess.  So, to decrease the likelihood of failure, I wanted to make sure we were on the right track.

The design they presented to me was overly simple, not showing the tie-ins to the rest of the system, and without really defining the new entity-types (that would become new database tables), or articulating their attributes.  I sat back a bit puzzled, and asked where the rest of the design was?  Where was the detail?

The team had been trained on a rigorous approach to doing this level of system design that forced out detail, but they hadn’t used it.  I asked my colleagues to gather their team, use the standard design techniques they’d been taught, and drive out a proper, detailed design.  I’d check in on them after a few hours.

A few hours later and a few white boards later, they did indeed now have the artifacts I was expecting, with full ERD, and the start of the detail they needed.  And in the middle of it were the three new entity-types they had in their earlier, simple design document.  I noticed they hadn't yet defined those entity-types, and our methodology required entity-types to be defined in a particular way.  When I asked about the definitions, they weren't able to come up with proper ones.  That was a red flag! 

Driving through the details of how they’d be used, it became clear that those new entity-types in fact represented relationships that already existed in the system.  Their design was about to duplicate existing functionality!  By the end of the session, we realised we already had much of what we needed in the system, and that the course of action to implement the rest was thus far simpler than what had originally been anticipated with the earlier, ‘simple’ design.  That day, there was about a million-dollar devil hidden in the details, and we found it.

That is only one example of many throughout my career where paying attention to the details has meant we avoided major problems.  The devil is definitely in the details, but there are ways of driving him out.  If you don’t, you assume risk, and without knowing the details, you won’t know just how much risk. 

This implicit assumption of risk because the project team failed to sufficiently dive into the details until it was too late is in my experience one of the most common causes for project failure.  The narrative is generally always the same: “Oh, well, event x happened, and we were totally taken by surprise, and so that delayed us for a month / we had to eliminate that feature to make the date / we had to bring in more people to make the date / that’s why the quality isn't as good as we’d like it.”

So, how do you drive the devil out of the details?  Here’s some pointers:

1. Good project managers should have an almost incurable desire to ‘understand it all’ – how it’s going to work, why it was done that way, why it needs to be that complex, or exactly why we can simplify things this way.  And they should crave for that understanding to be deep.  Questioning your team about their approaches should never be considered an affront to their expertise (and the project manager needs to make sure they understand that).  Rather, it is the project manager’s job to ensure that they are indeed coming up with the best courses of action, and so that takes probing to be sure.
2. That means a project manager should really understand the project’s domain, or have consultation from someone who is an expert in the domain.  Years ago I implemented a production-line-and-warehouse-automation system across the US.  I was the project manager, but also on my team was the warehouse manager from one of our plants whom I seconded for the project.  I knew he understood warehouse management and production facilities far better than I, and I knew I needed his expertise to be able to get into the details.  He was invaluable!
3. Be rigorous and use rigorous methodologies and techniques.  They don’t have to be heavy or bureaucratic, but they should drive critical thinking and force you and your team to examine the details.  For example, defining entity-types in a particular way as part of modelling data does that.  Your quality assurance plan and practice should also ensure there is sufficient detail in every work product along the way.
4. Always ask that standard set of questions: how big?  how much?  how many?  how fast?  how frequently?  Know the ‘size parameters’ of your project.
5. Understand the ‘exceptions’, and make sure they’re really exceptions.  Just because someone labels something as an exception that doesn't need to be considered, doesn't mean it necessarily is.
6. If you’re using a sub-contractor, depending on the nature of their work, make sure you understand in detail not only the interface points of their work and yours, but perhaps too exactly how they’re going to achieve what they’re supposed to be achieving for you.  Remember, if they fail, you fail too unless you’ve developed an appropriate contingency plan.
7. Watch out for “assumptions”.  I see them constantly in project charters / statements of work, and they are often black holes for details that will come back to haunt you.  While there may be justifiable cause to articulate some assumptions early in the conception of a project, assumptions should be eradicated as quickly as possible with vigour.  That means diving into the details behind the assumption to make it not an assumption, but either an already-true item, or part of your plan to make true.

A healthy dose of, “and exactly how is that going to work?” will go a very long way to keeping you out of hot water!

Read part 10!