The Most Important Thing

Last night I was interviewing a candidate and I asked him to tell me the value of a recent project for which he was the lead business analyst. He asked me what I meant and I clarified by asking him to tell me why was the project being done at all. He quickly replied "To facilitate the transfer of data between systems". Now I don't know what comes to mind when you first hear that, but I still had no idea of the value of the system. I mentioned that all enterprise software systems facilitate the transfer of data between systems. He thought for a moment, then went on to explain that the new system was going to be easier to use and would be easier to maintain than the legacy system that it was replacing. In fact it had the same functionality of the original system, it was a new easier to use platform. At this point I moved on, but it started me thinking about a topic that has come up recently in the office that I like to call "the most important thing".

What is "the most important thing"? Well if you have an MBA or if you are pretentious you might want to call it the primary user enhancement, killer functionality or crititical strategic functionality. I simply call it the most important thing. The most important thing is the key reason for why the software or software release exists.

On a recent project, the most important thing was to get a stable alpha release of development tools into the hands of client software developers ('the client") so that they could begin building on top of it. The most important thing implied a set of minimum functionality that had to work to allow the client to compile and debug their software. During the lifecycle of this first phase, many team members kept trying to add functionality such as nifty features to manipulate the hardware in various ways or code optimization features. Those features would eventually be important, just not for this first release. Keeping focus on the very simply stated purpose of this release allowed us to easily determine if something was in or out of scope and after much repetition, eventually people on the team were able to have this same focus. Based on this we managed to prevent a radical increase in scope.

On another project I was on a few years ago, we sat down with the client team and began discussing their complete list of features that "had to be done". Once the high level list was complete, we ran them through some estimating excercises to get a view of how long it would take. The developers kept saying they could implement 100% of the functionality on the list by the deadline, so the business team was delighted and was ready to go. We didn't think it was possible for them to complete even 50% of the functionality, so rather than try to figure out the maximum that could be done given the time constraints, we began having them cut scope by focusing on the most important thing. In this particular case it was key functionality that would allow the client to significantly reduce the time their call center reps spent on the phone with each customer. By the end of planning, we had cut 80% of the original scope. As it turns out, the development team struggled to finish even 20% of the functionality before the cutoff date, but they did deploy on time. Imagine what would have happened if they tried to deploy the original functionality.

We see this all the time, especially from very smart people. They get excited by the infinite possibilities of what could be and forget about what is really important.

My interviewee was actually very smart and seemed to have good consulting skills, so he wasn't hopeless, but if we bring him on board, we will definitely be teaching him to always think about the most important thing.