The What and the How
I was talking recently with a coworker of mine about the “what” and the “how” of software projects.
The “What” is the definition of the thing you are building. What customers should we go after? What markets should we serve? What competitors do we care about? What scenarios matter most? What feature should we have?
The “How” is the definition of the way you build it. How should we org the team? How should we ensure quality? How do we do SCRUM, Agile development, TDD, etc? How should we ensure customer feedback gets reflected? How should track progress?
Between these two areas, the what and the how, is the essence of software projects. When a project fails it is often due to one, or both of these having insufficient IQ on them. A project without a good “what” can flounder from exec review beatings to analyst lashing to customer ambivalence no matter how good the “how” is. A project without a good “how” can suffer delay, after delay, quality issues and poor team morale no matter how good the “what” is.
Think about the software project you are currently on… is it missing more of the “what” or the “how”? Do you have a clear idea of the product you are building and the customer you are targeting? If not, your team is missing the “what”. Do you have a good idea of how quality is ensured, how the schedule is created and managed? If not, your team is missing the “what”. Understanding the world in these terms can help you spot the issues, communicate them clearly to others and (hopefully) fix them!
Another interesting angle on this is that people tend to have inherent talents in one or the other of these dimensions. There are “what” people and “how” people and a software project needs them BOTH to be successful. If you are strong in one of these, it is certainly possible to be great at the other, but you will likely have to work at a lot harder at it. Once you have reached the competence in your weaker area, consider if you would be more successful overall (and happier) investing the time and energy into making your strength area even stronger. A “How” person that everyday has to come in to do “what” work will likely soon burn out… and vice-a-versa.
As any student of the Mars vs. Venus conflict can guess “what” and “how” people often deeply irritate each other. Have you ever been in a conversation about which feature would delight customers more only to be randomized by a rant about the schedule and the amount of time it would take to get those feature done? Likely you are a “what” person being irritated by a “how” person. On the other hand, have you ever had your orderly schedule review wrecked by pie-in-the-sky thinking on features 2-3 releases out? Likely you are a “how” person being irritated by a “what” person. Appreciating that there are “what” and “how” people and that they are both super valuable to a software project can help you bridge the divided.
What are your thoughts? Do you think most projects fail with the “what” or the “how”? Any thoughts on what has worked for getting “what” and “how” people to just get along?