A couple of years ago I had an extension built on my house. It was an interesting process – mostly satisfying but not without its difficulties.
It has been said that building software is very different from building houses, and that it isn’t useful to compare the two. Nevertheless, I think there are some interesting parallels, and in this article I am going to discuss them.
My wife and I bought our house 14 years ago. There was plenty of room for the two of us – in fact we had room to spare. Things were fine. But then everything changed – we embarked on an ambitious family expansion project. The project was a resounding success – we achieved a 100% increase in family size. Yes, we had kids – two of them.
That created a problem. Not at first whilst the kids were still young. But as they grew, the space they occupied grew too. Soon enough we were forever tripping over randomly discarded clothes, toys, limbs and suchlike. The space we were previously able to relax in was no longer a relaxing place to be. Setting the table for dinner generally involved an extensive craft activity clean-up session. Man, I hate glitter. So, we had a “problem space”. Or perhaps more accurately, a problem lack of space.
For a while, we executed the “do nothing” option. But as time went on, and our dissatisfaction grew, we started to consider alternatives. We started to wonder whether our space could be better organised – to reduce the contention and improve the relax-ability. First we looked at whether we could re-organise our existing space – to give us dedicated zones for eating, playing and chilling. But whichever way we looked at it, we couldn’t find a solution that gave a significant improvement.
So then we started thinking outside the box. Literally, I mean, not metaphorically. We started to wonder whether we could add space to our house to solve our “problem”. Again, we started tossing around ideas. Build out back through the dining room? Build out to the side through the kitchen? One storey? Two? Incorporate a garage to replace the one that’s falling apart behind the house?
We had plenty of ideas, but we weren’t sure which was best. And we had a feeling there was a better option that we hadn’t thought of yet. We needed help.
Hiring a ‘Building Analyst’
If you need your building requirements analyzed, what you need is an architect. A real architect, that is, not an IT architect! Now, like most families, we don’t have an in-house architect, so we went to the market, and found someone that we thought we could work with.
In our initial session, the architect came to the house and conducted an elicitation workshop. In the workshop, he explicitly instructed us not to tell him what we thought we wanted. Rather, he wanted to hear about us, what sort of people we were, how we used the existing space, and what we thought our problems were. So we told him about our space problems and tripping hazards. We told him of our love of cooking, and how the kitchen was a focus for family life – but that we didn’t like the way the kitchen got cluttered with dirty boots and clean washing. We told him that we liked lots of light, and that we’re keen gardeners. We told him that we wanted our living space to feel as connected as possible.
We talked for an hour or two and then we left him alone to do his analysis. Our only input to this process was to provide him with a nice hot cup of tea.
After another couple of hours, we re-convened and he showed us his proposal. It was presented as a visual model (he called it a “drawing”). Central to the proposed solution was a “sun room”, to be built on the side of the house, with an open-plan entrance through from the kitchen – with lots of windows for plenty of light, and a huge tri-fold door opening out onto the front garden. There was also a utility room for boots and laundry – and finally, the garage was to be re-built on its existing plot, with an all-important DIY workbench.
We then spent another hour or so discussing the proposal, and collaboratively making a number of refinements – a second door in the sun room linking through to the lounge. A pitched roof and an extra skylight. An enlargement of the garage to give some extra storage space. By the end of the day we had a sketch of the solution agreed. It was similar to one of the ideas we had envisaged ourselves, but included a number of features suggested by the architect that hadn’t previously occurred to us.
Over the next few weeks, the architect drew up a more formal set of drawings – first a draft, which we reviewed, and then a final version. These went to the local authority for planning approval, and were also used as the basis for the build itself.
Hiring a Development Team
If you need some building work done, what you need…is a builder. Like most families, we don’t have an in-house builder, so once again we went to the market. We got quotes from three local building firms. The quotes were based on the drawings, but also required a number of clarifications from us – did we want reclaimed stone or reproduction stone for the walls? Hardwood or softwood doors? Underfloor heating? And so on.
We chose the builder that we felt we could work with best. Luckily, he was also the cheapest, but a good working relationship was more important. He had a good eye for detail, and we could tell that he really cared about the importance of using materials that were authentic and sympathetic to the rest of the house (built in 1902).
And so the build began.
It wasn’t long before we hit our first problem. The foundations had been measured out and dug as per the drawings, but something wasn’t right – the sun room was the wrong size. Eventually we realized that one of the measurements on the drawings was wrong – it was inconsistent with the other measurements, in a kind of A plus B doesn’t equal C sort of way. So we called out the architect to take advice. He agreed that there was a mistake, and between us we worked out what needed to be done to rectify it. There was a somewhat heated discussion over who was going to pay for the alteration, but in essence we had our first change request, scribbled in pencil on the drawings. The alteration was made, and we were back on track.
But there were other issues to come. Most notably, there was a problem with the garage. At our request, the drawings for the garage included a main garage door (for vehicle access) as well as a separate personnel access door, and a window. But the constraints of the physical materials meant it would be pretty tricky to do this. So we had to choose – keep the access door, or keep the window? We decided to keep the window. This decision was agreed directly with the builder – we didn’t bother getting the architect back on site – and we didn’t update the drawings either.
There were a number of other alterations and enhancements as the build went on, such as the inclusion of some genuine reclaimed finials for the roof, for which the builder had to hunt far and wide. It really helped that my wife was on site during the build – she was able to make quick decisions on all sorts of matters of detail. Most evenings we would have a look over the day’s work together and make a note of any issues/concerns ready for the builder the next morning.
A Happy Customer
All in all, the process worked well for us. We have a beautiful new sun room. It has lots of light and a great view over the garden. We achieved our original objectives and the result is better than we ever imagined. I am sitting in the sun room as I write this article and I think you’ll agree, it’s adding something to the quality of the words.
As mentioned at the start of this article, it is not necessarily valid to compare building design with software design. And also, this was a small building project with just two stakeholders, so there is limited value in trying to learn lessons for large IT projects. But I’m going to do it anyway!
My first observation is that the building architect was a designer. Like a business analyst, he was responsible for engaging with the stakeholder and understanding the problem space, the objectives, the “needs”, the “requirements”. But he was also responsible for providing a solution, a design. He understood the possibilities and constraints of building construction well enough to be able to say not just what was needed (or perhaps better, wanted), but what was to be built. There wasn’t a building analyst separate from the building designer – it was one and the same person. He didn’t deliberately avoid solutionising – his role was to solutionise.
In my experience, a lot of business analysts don’t work like that. They see themselves as the custodian of the “requirements”, and it isn’t their job to design, to solutionise – that’s a job for the technical team. If you’ve read any of my other articles, you’ll already know that I don’t agree with this view. In my view, it’s all design, and things work better if the business analyst does solutionise, to the point where the customer knows exactly what they are going to get.
That’s exactly how I try to work as a business analyst – I listen to the stakeholder’s problems and objectives and I propose solutions. Often I propose alternative solutions: some better, others cheaper. And the specification I produce is a statement of what is to be built, not a statement of what is (perceived to be) needed. I don’t write down the requirements and hand them to somebody else, one step removed from the stakeholder, to produce a solution. I do it myself.
My next observation is that the building architect’s documentation was highly visual – a set of drawings of the thing to be built. As a stakeholder, that made it much easier for me to visualise the end product. Now, of course a building is a highly visible thing – it consists mostly of static structure, with only a few moving parts (doors, for example). It makes sense to model it in a visual manner, and it’s relatively easy to overlay the behaviours of the moving parts on the model (for example, by drawing an arc to show the path of a door opening).
Software, however, is much more about dynamic behaviour, which is much harder to visualise because it happens in time, not space. User interface layouts are easy enough to visualise, of course, but showing how the UI behaves in response to the various user actions is harder, especially given that users often do unpredictable things that need catering for. But that doesn’t change the fact that visual models are easier to understand than purely verbal documentation, and I’m a great believer in finding ways to visualise software designs (see my article on a graphical functional specification for more details).
My next observation is that the drawings formed the basis of a fixed price contract between us and the builder. The drawings gave enough design detail for the builder to be able to make a sensible estimate of cost and time. When a flaw in the drawings was uncovered (the incorrect measurement), we were into change control and additional costs were incurred. But the builder also included some contingency and was willing to bend the specification when it came to matters of detail – for example the sourcing of the reclaimed finials. Within reason, he didn’t just do the quickest and cheapest thing that was “fit for purpose”.
My experience in IT is that fixed price contracts get signed on the basis of “requirements” documents which don’t have sufficient detail – and then there are lots of arguments and lots of costly change control due to differing interpretations of the “requirements”. I’m actually not a fan of fixed price contracts myself – I think one of the big differences between buildings and software is that it is so hard to visualise software up front, you can’t be sure whether the design works until you actually use it. This is, of course, one of the central tenets of agile/iterative delivery.
My final observation is that once the specification was completed and agreed, the design work didn’t stop there. The grand plan was in place, but design decisions were made on a daily basis throughout, collaboratively between us and the builder, and based on feedback on progress so far. That was possible because of the physical co-location of the stakeholder and the builder on site.
There’s a clear parallel here in terms of access to business stakeholders. The most successful projects I have worked on have had easy access to a key decision-making stakeholder. In his book Crystal Clear, Alistair Cockburn refers to “osmotic communication”, the phenomenon of absorbing (and contributing to) the conversations that are going on around you. On my current project, the stakeholder is sitting on the same bank of desks as the development team, and it’s working really well.
It’s All Design
I have a close friend who is a successful (building) architect. In preparation for this article I had a long discussion with him about his job, and the process he follows. His answer in full is the subject of another article for another day. But in summary, he considers himself to be first and foremost a designer. And that’s how I consider myself too – a designer. After all, it’s all design.
There are many useful points in this article but the oversimplified conclusion “It’s all design” is as wrong as “total isolation of analysis and design”
Analysis is NOT Design. Both are distinct and necessary. They are related and mutually interdependent and cannot be carried out WITHOUT INTERELEAVING in practice (particularly when the requirement and solution are NEW).
In this case building architect is actually an “Analyst & Designer” and has actually played both roles. It is NOT “all analysis” NOR “all design”. That would have never worked.
I agree that strict isolation of “requirements” without “any awareness and some kind of use of design” would be a serious mistake. At the same time, it is important to recognize that what an architect does is an overall solution design to meet the requirements or the purpose of building. The specifics of actual design and construction affect and modify the solution and even the requirement.
So what we call BA may still be valid if it means Business Analyst & Architect. That is quite different from Software Architecture and Implementation.
This apart, the specific nature of software will have to be taken into account when one gets into details.
Putcha, to your point…
The role of a BA is essentially ‘understanding’ (via analysis) AND ‘design’. The analysis deliverable identifies whats for business consumption. The design deliverable specifies how (functional requirements) for solution team consumption. Separating hows from whats is for the benefit of the business. Including hows in a requirements document for business review and approval burdens them with irrelevant details, and it typically distracts them from understanding (and approving) scope and capability.
I recognize and recommend distinction of Analysis and Design. I do not know what in my post indicated anything different. I did say they need to be “interleaved” NOT mixed up. For doing so, both the skills of analysis and design have to be mastered.
I was agreeing with you.
Duane: It is so rare to hear agreements that I failed to recognize one from you. Thanks.
From a stakeholder perspective, BA artifacts may very well be “all design.”
From a developer perspective, BA artifacts may be considered “all analysis.”
The BA needs to recognize and respect both perspectives. So yes, it’s all design; but arguably, it’s also “all analysis.” But in reality, it’s both analysis and design.
As Putcha said, building architects fulfill both roles. They can do so because they only have one customer, the home owner. The BA has two customers: the business and the solution team.
Putcha, to your point…
I never get the impression from Tony on any of his articles that he does not distinguish between analysis and design. I think the point is rather that there is no such thing as a requirement and I agree 100%. Any requirement is someone elses solution design to a problem or opportunity statement higher up in the chain.
Why fades to what, what fades to how when viewed from a fixed perspective.
Thanks for your comments. I agree that analysis and design are interleaved – in my experience, there’s a back-and-forth process that eventually converges on an agreed design. The main point of the article was to point out that the building architect does both – there is no “building anaylst” separate from a “building designer”, and I think that’s a model that’s worth adopting within IT tool.
Put another way: I’m not a Business Analyst – I’m a Business Analyst Designer.
Good point Tony. A building architect identifies the need and purpose of the building in an integrated manner (holistically) without getting into details. That is of great value to the customer. That’s why I too say a BA is a BAA.
Pingback: I'm Not a Business Analyst - I'm a Business Analyst Designer | its-all-design.com