More Evidence that constraints drive solutions

I believe that constraints are usually a blessing, not a curse. Not a new idea, but certainly one that gets reinforced every time I see a project with a vague concept or definition meandering through the early phases. Some sort of limitation, whether it’s resources, time, or something else almost has to be in place in order to keep things moving. Otherwise a project runs a real danger of becoming a Christmas Tree Bill, as various parties attach new features or requirements to it. Or the project is prone to picking up a lot of features that are further and further away from the core idea.

Apparently, certain Military contracts are subject to this too. [via Greenspun] Here we have a helicopter that only generally gets used for 15 minutes at a time, but now it’s a flying, super-advanced telecommunication system, with state of the art defense systems, extended range, etc.. I think it’s a victim of constraint-less project specification.

Everyone involved wants to do everything they can to protect the president, which means spare no expense. Hence you’re going to end up literally, with a result that can’t get off the ground because it’s too weighed down by features. It takes constant vigilance to edit non-essential features out of existence before they complicate your product and your code base, and as BA’s we’re the first line of defense.

Estimating the Analysis Process

So it’s clear to me that I’m coming at business analysis from a different place than a lot of people. That is very obvious when I catch articles like this one on Estimating Analysis Time from the Business Analyst Blog.

An important BA skill is the ability to accurately estimate the amount of time required to perform analysis work and be able to explain and justify it to project managers and sponsors.

I’m completely unclear as to how such an activity can be considered an important part of getting software out the door. Your stories/requirements/whatever are feeding the whole team; you’re the first person in the assembly line. It should be obvious the time they take and the value, because without them, every downstream team will be idling.My gut feeling is that it’s only in extreme cases of divorcing analysis from construction that anyone would even ask for these estimates. They should be reflected in the total volume of software produced, and I’d say that if your metrics/estimations aren’t based on total volume including all the activities (testing, analysis, development, engineering, etc.) then you have bigger problems.

Context and Software Process

As I start to post more here, some if it may seem like I’m full of rhetorical antipatterns about my beliefs in software development and the analysis process. I want to make my context clear, in advance.

The ideas here are predominantly about building business software in a large organization. That’s the hear of my experience. A lot of the observations will be anecdotal, because it’s very, very, very hard to accurately measure productivity. Not only is it almost impossible to measure in the absolute, even relative measures can be suspect (Robert Austin covers this much better than I could in Measuring and Managing Performance in Organizations.

So I’ll be the first to admit, there’s not a lot of science here. Some would argue it’s sloppiness, some would argue that it’s just inherent to the task. What is there is just my personal experiences, observations, and thoughts after years of building software in this context. When I say something inflammatory like “traditional requirements specifications suck,” I mean in the context of a rapidly changing business environment at a large organization consisting mostly of non-software professionals. I am not claiming that any such assertions then apply equally to other fields, like shrink-wrapped software, or military radar systems. They may apply, but I have no idea.

Editing your Software

The crew over at 37signals makes a great breakthrough in terminology by declaring that software needs editors. That’s a wonderfully succinct definition of a role that has not been talked about a lot in the past. The general process is “business owner” comes up with ideas, analysts distill those to requirements, and finally developers implement requirements.

That leaves the “business person” responsible for editing the features, and completely in charge of the process. I suspect this works reasonably well in software for sale markets, because the business people are really just proxies for customer demand. Presumably they are looking at all sorts of marketing data, customer surveys, customer behavior, etc. to determine what features should go in. Their core competency should be this editing role.

In “enterprise” development, who performs the editing role though? The business people should be experts in their domain, be it stock trading, banking, auto manufacturing, health care, or whatever other domains we can dream up. They are the authors and the writers, and I think it’s the business analysts’ role to act as that editor figure. Not authoring, but shaping, directing, and molding the raw ideas.

I think that’s the analysts’ role because the BA works closely with the developers too. And unlike editing a piece of writing, there are technical concerns around what goes in or out. The complexity and maintenance costs of implementing a feature one way or another, or of leaving it out entirely aren’t up to the whims of the analyst (or the original business owner). It’s really a team effort, but the analysts need to feel empowered to guide the process, and provide data and hard justifications for why something does or doesn’t make sense to be included.

The important thing, like the 37 signals guys said, is that software isn’t just a bunch of checkboxes. When company websites are rated by third parties in terms of checkboxes on a feature matrix, it can be easy to forget that what’s good for your rating might not be best for the customers.

Do we want scientists or engineers? Neither.

Alex Hung asks Do we want scientists or engineers? for developers. If you’re talking about the current output of computer science vs. software engineering curriculums, I don’t think it matters much. Neither has the skill set straight out of college to be effective, and if the person has the potential, both are equally as likely to grow into good developers.

The activity of software development (in a business context that I’m used to dealing with) is not computer science or software engineering although it contains shades of both. It also contains a lot of written and oral communication, a little bit of aesthetics, some history, and a lot of information about whatever domain the software lives in. The most valuable people in a business software development environment consistently seem to be those that bring those extra skills to the table.

I rarely find it to be the case that the smartest developer, or the best coder, or the most educated is looked upon as the best developer on the team. How to identify and teach the extra skills that make up the discipline is still I think and open question.

What does a business analyst do?

I noticed a while ago that if you go to the International Institute of Business Analysis web page, click on “About”, and then go to What is a Business Analyst? you get a blank page.Okay, so you if then actually click on the “What is a business Analyst” on the blank page, you then find out:

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

I think if you boil that down to it’s essence you get a good starting point, but it doesn’t really get to the core value. “enable the organization to achieve its goals” is the core value proposition in that definition, but that’s every employee’s goal, so it doesn’t seem that interesting. So I’m setting that one aside and making my own (it wouldn’t be deconstructing the role if I didn’t start with an alternate position).

A business analyst facilitates turning ideas into working software, and evaluates the success or failure of that software against the business goals.

You could tweak the “working software” part depending on exactly what sort of business the BA was working in, but that’s the one that’s right for us (we build the customer-facing website for a financial institution). It’s a wide open definition, because I see the BA role as the glue that brings teams and ideas together. Modern software development teams should understand the business, the domain, the problems, and should be perfectly capable of sitting next to an actual business person to define requirements or stories. But in a large organization, just finding and keeping track of the real business owners who deeply understand the business model can be a full time job.

So my working theory is that the modern BA is a coach, relationship builder, secretary, gopher, project manager, etc.. It’s a broad skill set, and one that’s challenging to find or develop in people. The other option is to retreat into documents. Talk to the business people, turn what they say into written requirements, and hand them over to developers. I think that’s not the way to go. The BA role sits in what I think is the best place to manage the end to end life-cycle of a system.

Review: Behind Closed Doors

I just read and finished Behind Closed Doors over the weekend. It’s a very quick, very good primer on how to be a good manager. I’m spoiled because I’ve worked for an absolutely fabulous manager for three and a half years now that does everything in this book and more. I’ve done a lot of reading on management (for a developer), and I recognize lots of bits and pieces from other books in this book (yes, they are properly attributed).

So this book is a great, simple place to start for new managers. My one criticism is that it almost makes it look too easy. The difference between bad, average, and good is fairly subtle, and I don’t know that if you haven’t been studying under a good manager that it would quite as obvious how to proceed.

For me it’s a great start though; a quick retelling in a practical sense of a lot that I’ve read over the past year or so, with a lot of restatement and checklist-style presentment of things you can use to remind yourself of what you should be doing. And then you have all the references to follow up on, which you’ll need to because there is very little discussion of the theories behind these ideas.

Still, very fast read, very practical and useful immediately for beginning managers.

I’m here on purpose.

I’ve been writing software to support businesses for 10 years or so. First as a system administrator then as a full time developer. I’ve worked on systems large and small, for many platforms and on many languages, and solved many thorny technical problems.

 So now, somewhat to the surprise of my friends and co-workers, I’m switching gears. I’m moving into business analysis. The idea was first posed to me by a friend of mine who wanted me to work for him. It didn’t take long to decide that this was the direction I wanted to go, and now here I am, starting in a new direction as a business analyst.

The why in “why do you want to do change roles” is simple. I know what I’ve seen with my own eyes on projects; those with good to great BA’s deliver better software without burning out the team. When the BA role goes missing, as it so often can, you tend to end up with software that just doesn’t do what you want. So I want to see if it’s a role I can develop, institutionalize, and make a bigger difference in the quality and quantity of what we deliver to customers at the end of the process.

I’ll be sharing more thoughts about the role as I have them, and tips, tricks, or whatever else makes the job easier. Wish me luck.