Conducting a Tech Briefing Session

Reviewing the spec with programmers before they code.

A business analyst or project manager often gains a deep understanding of a client's business during the scoping phase. Probing questions during this process create a contextual back-drop for the project. Why is context so important? Because it makes you care, otherwise it's just another IT project. Having context mixed with experience and intuition results in the right questions being asked. If these questions aren't asked early on, trouble may ensue later down the track. For example, a paper-based task which the client takes for granted may in fact be a technical nightmare to implement (potentially jeopardizing the feasibility of the project).

Unfortunately, programmers often miss-out on this context. Developers are stuck in the office cutting code whilst analysts are out hobnobbing with clients. It would be unrealistic to expect programmers to attend all these client scoping meetings, if they did than who'd be back in the office doing the actual work? This is not even factoring in that documenting requirements is a particular skill-set, something a programmer may not have cultivated by this point or even be interested in.

The standard in most teams is to relay requirements to developers via specification documents. Whether that's a separate functional and technical spec, or just one document, in either case this document forms the basis by which a programmer turns concept into reality. But handing a spec to a programmer and saying "here, code this" isn't enough in my opinion. A spec often won't have context, sure, user cases help a lot, but they can often be limited, and a printed spec doesn't answer questions a programmer may have.

This is where a technical briefing comes in to fill the gap. The attendees would be the project manager, the business analyst, and any programmers who have been assigned tasks on the project. As to how much time will be needed, that depends on how big the spec is. What you are doing is going through the spec screen by screen, reviewing each interface in detail, discussing underlying functionality, stopping to answer questions, and providing contextual background which may be missing from the spec (e.g. what the client's business does, what systems they currently have in place, etc).

What's wrong with just giving programmers the specification and asking them to read it - you do trust your developers don't you? This is an important point; a briefing meeting may send the message that you lack faith in your technical team. The meeting does seem like a hand-holding exercise. Personally, I hate taking any action as a PM which diminishes a developer's chance for self-autonomy. But I hate failing at a project even more.

At the end of the day, if you hand a spec to a programmer and say "here, read this", they may very well read it. Or they may not. A programmer's primary focus is to cut code. They may be over-worked and under pressure themselves. Sending programmers in to code without arming them with context is like sending your troops to capture a machine gun bunker without weapons. They are part of the team, so why wouldn't you do everything in your power to set them up for success?

Another reason to undertake technical briefing sessions is because of the impact it will have on the type of bugs logged during the QA cycle. Without a tech briefing session, you will find a significant amount of bugs being logged for missed features (i.e. features in the spec which weren't coded). When enough 'missed feature' bugs are logged, you can start to deduce a pattern. A pattern that indicates that the programmer didn't absorb enough of the specification - they may have read it, but it just didn't sink in.

Once inside a tech briefing meeting, programmers can't escape; they have no choice but to sit there and absorb the business domain. A tech briefing done right will drastically reduce bugs which occur because of blank areas in a programmer's understanding of the system (anecdotal proof for this can be found during the project post-mortem bug analysis). The time alone spent on not having to fix these kinds of bugs makes up for the time the programmers spend in the meeting.

So is a technical briefing session just about not trusting programmers? No, it isn't. It's also about buy-in and caring. If programmers care about a client's business, they are more likely to do a good job. As I mentioned earlier, a BA or PM has had the benefit of many meetings with a client, a programmer hasn't. The tech briefing session gives you the opportunity to transfer some of this knowledge to the technical team. It's likely you will be able to condense this knowledge and feed it to programmers at a more concentrated level.

A typical agenda for a technical briefing would look something like this:

10.00am - 10.05am: greetings and hellos (Everyone)
10.05am - 10.20am: background on client's business (PM/BA)
10.20am - 11.20am: screen-by-screen review of wireframes (PM/BA)
11.20am - 11.45am: programmer Q&A session (Programmers)

The real magic happens during the screen-by-screen wireframe review. This is where you can inject a great deal of unseen detail. You can spend a few minutes talking about the rationale behind a particular screen. This could be a big deal because without it, a programmer could be looking at a complex wireframe and not even realize how critical it is to the operation of a business.

In terms of location and format for the meeting, ideally you would want to book the board room for a couple of hours, but if that's not available, any quite room away from computers will do. If you can get your hands on a projector to display the mock-ups for everyone to see, great. If not, big A3 color print-outs of the mock-ups will do. Should programmers be required to take notes during the meeting? I don't think so, leave it up to them to note down whatever they want. The main point is for them to listen rather than bury their heads in a notepad or laptop.



The sort of returns you can expect from conducting a tech briefing session aren't realised until the end of the project. The time you spend early on relaying context to developers will more than pay for itself later down the track. Programmers won't need to approach BAs or PMs as often to ask questions, they probably already asked the question during the Q&A segment of the briefing meeting. Fewer bugs related to missed features will be logged, and programmers are less likely to make bad assumptions about ambiguous features considering they have some understanding of the business rationale behind their work.

Subscribe to RSS Feed.