We technologists are often being asked to deliver things that are impossible given the constraints within which we must deliver them. Delivery of web solutions is one such area.
The problem begins with business people who have some ideas about what they want, but who do not understand the technical domain sufficiently to understand how expensive or complex those wants are to fulfil.
Some of the issues include: understanding the real business requirements; finding effective ways to listen to the needs of business owners; helping business people understand trade-off options to meet client and end-user needs; how to move beyond egos and agendas to the real issues; and how to clarify business requirements to meet expectations.
Another important thing we need to achieve is how to explain the advantages and disadvantages of requested web projects. In the short time available I will attempt to address these issues.
Miscommunication is at the root of all problems between technologists, business owners and end users. Very often one party is from Mars and the other is from Venus, or even Pluto.
We often go into discussions as if we are all working from a common basis of understanding. But the truth is very different. Each party bring to the conversation a different perspective, set of expectations and base of experience and knowledge. This makes for a challenging mix to manage. It also makes it challenge to keep everyone happy.
Steve McConnell has written about this problem and characterises it in terms of building a dog house:
“ People who have written a few small programs in college sometimes think that writing large, professional programs is the same kind of work-only on a larger scale. It is not the same kind of work. I can build a beautiful doghouse in my backyard in a few hours. It might even take first prize at the county fair's doghouse competition. But that does not imply that I have the expertise to build a skyscraper. The skyscraper project requires an entirely more sophisticated kind of expertise. The difference in complexity between student programs and professional programs can be just as great, and non-professional programmers -underestimate the difference in required expertise at their own peril.” (McConnell, 1996)
Some of the important issues we have to deal with include: software is not always simple to build; integration with existing systems can be a challenge; we often have legacy spaghetti code; and new code can be just as complicated to build, deploy and maintain.
It is our job to be able to explain the difference between building a dog house and a skyscraper to business people. But firstly it is our job to understand what they really want and need. Bearing in mind that wants and needs are not necessarily the same thing.
Sometimes a seemingly simple request from a business owner can actually require a series of complex and risky changes. I’ve often had someone ask if we can change just one little thing on a web screen.
The request might actually require a web front end developer, API developer, database developer and a tester and take them each a minimum of one day to complete. Assuming a base rate of $1,000 per day per resource, that one day of duration is actually four effort days and thus a minimum cost of $4,000.
Often the business owner does not get to have a discussion regarding how this cost aligns with their wants and needs.
Business people do not have a mental map upon which to plot the combination of their desired functionality and designs and the effort, cost and complexity of achieving them. It is up to us to explain to them the trade-offs required. There are many ways to deconstruct this, some of the key criteria are:
Novelty of the desired solution
Complexity of the requirements & the technical environment into which it will be deployed
Ability to re-use existing applications and code
Degree to which the desired solution has to connect to legacy spaghetti code
One of the big challenges we face in delivering solutions to business owners is truly understanding their wants and needs and the difference between the two.
This is where we return to the idea expressed by Charles Dickens about needs v. wants and budget. If the business owner wants a highly complex project with novel functionality (a.k.a. a Ferrari) but only has budget for a simple project that reuses existing functionality (the a.k.a. Nissan Micra) then it is time for the discussion on needs v. wants.
It has been estimated that conversational “speech is produced at a rate of about 2.5 words per second, often in noisy environments and with less than-perfect articulation.” (Krauss, 2002)
This means that the spoken word is probably one of the more inefficient ways to communicate with the business owner. Especially when you consider that, given the dearth of meeting rooms, the meeting will likely be held in a noisy coffee shop.
For example, where the business person explains their requirements and it all looking nice and simple. But they finish off with the throwaway line that “and we’d like that to email us if it does not work”.
Thus with this implicit requirement, it is now possible that your simple project requires scheduling functionality, an email gateway, error checking for transmission, etc. A small project just got a whole lot bigger.
Set S.M.A.R.T. goals, e.g. audience reach, level of engagement, dwell time on site
Define metrics for success
Ensure you write great content specifically for web
Example I use this as a simple introduction for the business so that they understand some of the things I will ask them to contribute to the success of the web project. It leads nicely into the engagement model and project team charter.