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?

Comments

• Anonymous
  October 07, 2006
  My experience is that it fails equally from both the "What" and "How" ends of the spectrum. The challenge is to get the "What" people to describe the "What" and not the "How" and to keep the "How" people from altering the "What".  In projects where this is accomplished we will usually see a higher rate of success and satisfaction from both groups. Much has been wriiten about this.  There are also scads of tools that claim to make this possible. Every project needs to start by developing it's own definitions of the "What" and the "How".  That is to say define what "What" is and what "How" is to that project/organization. Some guildlines on how to do this would probably be a helpful starting point.

• Anonymous
  October 07, 2006
  Brad, I could not agree with you more.  A great topic and subject.  I say this because recently I have been struggling with trying to identify what in the world is the matter with a team and project I have inherited that is riddled with issues in the "what" AND "how" areas. The issues are so engrained I have taken the approach that I have taken a similar approach to what you describe in order to level set.  I have tried other approaches that have not met the level of success I wanted.  I feel like I am peeling an onion that has no center. You name it and there is a problem.. process? Yup. talent? Yup. morale? Yup. developed code? Yup. The excercise continues with going through every troubled area and asking the questions just like you mentioned and then some.  Then ofcourse the hardest part is to answer those questions to hopefully come up with a plan to make sure the project can be brought to stable ground and succeed. Obviously my comments are in context to a project that has already been underway for sometime while you took it moreso from the approach of a new project. Just wanted to write my views and agree with your post. Thanks. -JR

• Anonymous
  October 07, 2006
  The comment has been removed

• Anonymous
  October 08, 2006
  I agree with Puneet.  Some form of feedback loop can enhance the process and keep it on track but, be careful, this can also have unintended side-effects.  I believe it will only work well as long as the final "What" is agreed on by both parties. I am also a big believer in building quick "proof of concept" modules  at various stages to help validate that both sides are actually communicating the same thngs.  In most cases these POCs can be nothing more than dummy forms and reports hat serve as visuals for discussion.  In the case of process design flow charts and state diagrams can serve a similar function.  This should be kept at the highest level with little reference to underlying technologies. I always try to keep in mind that the user community has a need that we must find a solution to.  A solution cannot be selected before there is a complete understanding of the need from the users perspective. Worst Case:  We tell the user that what tehy are asking for can't be done.  I have seen cases where a project has failed because this was the case.  Legacy databses as sources can end up in this scenario because the information doesn't exist to begin with.

• Anonymous
  October 08, 2006
  Hi Brad, replace the wod "what" with "analysis", "how" with "design", "what-people" with "Analysts" and "how-people" with developers. That's the real world example. And sure I agree with you. A project without good analysts will also fail like a project without good developers. All need to come together. But be aware: Never try to make a developer become an analyst, or the other way around. I never saw at least one lucky case in that this solution would have worked. So I agree with my previous speaker that it is the best way to release a project very often, to integrate the customer and to listen to the analysts. Otherwise developers won't have an idea of the "what", and analysts won't understand the "how". Cheers Gerhard

• Anonymous
  October 10, 2006
  I think both what and how are equal players in the success/failure in any project. I also think each of the what and how questions could be improved with a follow up "why" question. Questioning why we did what we did and why we did it the way we did it (how) help us to reflect on the past and keep us open to the future.

• Anonymous
  October 10, 2006
  I like this.  A lot of good issues are starting to surface. I suggest that the "Why" is really part of the "What".  Knowing why something is required helps to define teh requirement more specifically. Another kind of "Why" might be what we cal a "Post-Mortum" of the project.  I have always felt that this is a must for every project.