Little Change In No Silver Bullet

While I was doing some offering re-read a  classic article that I remembered from my old battered copy of mythical man month called “No Silver Bullet”.

What it drove home to me was how absolutely central the work we do as BAs is to the value that IT delivers to an organisation, regardless of whether it’s always visible. It’s an old article (1987) but still as valid as the day it was written.

Article Text: http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html

Lecture Notes on Article: http://www.cs.colorado.edu/~kena/classes/5828/s09/lectures/02-nosilverbullet.pdf

What struck me most was how little the fundamental problems of building solutions have really changed. Especially this quote “I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.”

What we do is probably the hardest part of the solution development process, and the part that adds the most value. If the PM, Arch, and implementers all do their job fantastically then the best result is that the solution is on budget and on time. If we do our job well then the system that we deliver can make a real impact on people’s day to day lives, how well they do their job, and the effectiveness of their enterprise as a whole.

  

P.S. Some of the article is a touch dated. Time-Sharing is no longer a big change for example, and OO is not an innovation anymore; However Ada remains sadly under-used. Other bits are very prescient, such as a move towards iterative change driven development (e.g. agile), buy-vs-build, and even a touch of cloud.

Setting Scope in Dimensions

Scope definition is the most contentious, and most useful, of a BAs tasks early in a project. It's a key part of mitigating the project's risks by promoting consensus on aims.

 

Personally I'm most happy when I can promote disagreements over scope within a project. Too often people are using the same language to say two different things, and do not realise there's been a disagreement until too late. A disagreement is proof that I've been successful in bringing this misunderstanding to the surface early, so it can be dealt with during initiation instead of implementation.

 

My favourite way of doing this is by describing scope in three chunks:

• In-Scope: My responsibilities as a project
• Out-Of-Scope: Things that will not be delivered or considered
• Dependent-Scope: Other people's responsibilities, that my project relies on

 

Out-Of-Scope is In-Mind

 

The best way do this is in the out-of-scope section. It's really the only scope section worth mentioning. Seeing a chunk of scope as explicitly out is much more confronting than it not being explicitly included. It's for wishful thinking to take over, and for stakeholders to see what they want "in-scope" if something related is also there, the out-of-scope section removes this false comfort.

 

In Your Scope is Out Of Mine

 

Dependencies on other projects should also go in the scope section. Theses are essentially things your project will not deliver, but is expecting others to do. Inviting the responsible parties from these projects to sign-off on your scope is an opportunity to get disagreements sorted early. Nothing focuses the mind like having to put pen-to-paper on a document that explicitly says what you are responsible for.

 

Multi-Dimensional

 

Explicitly structuring your scope statements around which 'dimension' of scope they refer to can make your scope clearer, encourage you to think about the projects in different ways, and make a point unavoidable by restating it from three or four different angles.

 

Each "dimension" of scope is a single narrow class of items that may be in or out of scope. I've listed a partial brain-dump of the dimensions you could use below.

• Problem: User issues to address or ignore
• Functional: User facing features that are included or excluded
• Non-Functional Requirements: All non-functional requirements can be part of scope, either as area we are targetting to improve, or where we make no promises. (Note that I'm a big fan of phrasing these as negative NFRs - things we can do without is what drives intelligent compromise.)
• System: Which technical systems we are responsible for, or will not change
• Interfaces: System interfaces or integrations that we take responsibility for changing, or normally rely on others for
• Activity: User activity or tasks considered, or ignored (Useful as part of a process when you highlight activities to automate or stay manual)
• Users/Customers: Which user bases are considered, and which excluded
• Organisational: Parts of the organisation whose issues and needs are in scope - very useful when deciding stakeholder and interview lists.
• Legislative: Which parts of law are to be complied with, or whose compliance is a main point of the program
• Deliverables: What documents, sing-offs, or artefacts are included
• Detail: How much details (Descriptive vs Prescriptive) will be included
• Supporting: Which activities or systems will be able to function based on our delvierables. This one's quite useful to say you will produce just-enough to support a particular activity or example (say, estimation) but not enough for another (say, full-build)

Logo for Android

I am really enjoying having Logo on my phone. Making that little turtle run around takes me back to first learning about variables and sub-routines on an Apple ][e. Good times.

 

This is almost definitely my geekiest post ever.

---

This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. You should immediately delete the message if you are not the intended recipient. If you have received this email by mistake please delete it from your system; you should not copy the message or disclose its content to anyone.

This electronic communication may contain general financial product advice but should not be relied upon or construed as a recommendation of any financial product. The information has been prepared without taking into account your objectives, financial situation or needs. You should consider the Product Disclosure Statement relating to the financial product and consult your financial adviser before making a decision about whether to acquire, hold or dispose of a financial product.

For further details on the financial product please go to http://www.bt.com.au/general/rse.asp

Past performance is not a reliable indicator of future performance.

In Praise of Context Diagrams

The context diagram is probably the most neglected part of a BA’s bag of tricks. Nothing gives you the ability to collaborate with people so easily on a solution. A single slide with a good context diagram neatly summarises exactly what some functional component does, and who it serves. Whether it’s for a whole company, a system, or a software component, the context diagram applies just as well.

There’s lots of fancier ways of doing the same thing that give you a lot more information on context, aims, implementation, and scope – but none of them are so useful as tools to collaborate.

The beauty is that all you have to do is sit people down in a room, draw a circle in the centre of a white board and ask people who uses it. You then draw the users around in an arc in the top half of the board. Then ask what systems we rely on, draw those in an arc in the bottom half. Now ask what each user/system does with the solution and draw these requests and responses in as the arrows between external participants and the system.

It’s not fancy, there’s no certification course, but it can be the most useful meeting you have the whole project if you get it right.

Also, if you’re an external provider you can make these diagrams look very slick as you’re not restricted by a particular notation or layout. These give you a great way to advertise your competence, while displaying that you’ve understood the context.

Now – tricks!

• If you’re scope doesn’t cover the whole diagram you can use highlighted areas of the diagram to show in/out of scope, or multiple stages.
•  The MS Visio shapes for work flow diagrams and departments are a great source of icons for actors
• Minimise the number of systems you show, it should be mainly about users, systems are only their if they’re really significant.
• Maximum of four lines between any one user and the solution
• The “solution” in the centre of the diagram doesn’t have to be a system; it can be an organisational function, group, process, physical object, or anything really.
• If it helps – think of it as a top-level data-flow-diagram. But I don’t even know if they teach structured design in IT courses any more so that may not help you.
• Each arrow from users/systems to the solution could end up as one or more use cases or as a story grouping.
• Arrows going between users/systems to the solution can be verbs to capture actions, or nouns to capture data transfer. If you can stay consistent that’s nice, but it’s not %100 necessary.

P.S. In fact now I come to think of it most of what I learn in Structured System Design is generally under-used by the larger community. Perhaps because there’s no industry consortiums or consulting houses to push the method like there is for UML, BPMN, RUP, Agile, and all the other usual suspects?

Traceability and Business Rules in Word

A really good LinkedIn question from Adriana Beal on LinkedIn prompted me to write-up a neat little MS Word trick that can be useful for managing requirements traceability or business rules in MS Word.

It lets you create create consolidate of text scattered throughout your word document in a grouped list at the end using the same mechanisms as Tables of Contents, Indexes, and Tables of Figures.

This lets you do things like:

Reference business rules throughout your document and then include them all in

one appendix

Show a list of all Use Cases in your documents

Show a list of which Users, Screens, Systems, or Data Entities are involved in each Use Case

These are the basic steps:

• Create a custom paragraph style in world name it something like "Business Rule"
  
• Every time you reference business rule in your document put it on it's own line and apply this style (In our project we had a special section in each use case for the business rules)
  
• At the end of the document create a custom table of contents that lists all of the Business Rules in your document (Right click table, click edit field code, select field options, and you can then select which word styles show up in your table of contents). The resulting field code looks something like {TOC \f \n \h \z \t "Business Rule,2,Use Case,1"}
  

If you want a sample document that shows how to apply this style I've shared one from drop box: Sample File Download. The major downsides are:

• It's restricted to a single document
  
• You have to be a bit of a word nerd
  

Honestly it's a realy pain, and if you have an options you should use a wiki or a real requirements management tool. This is just a last ditch option to make requirements in word a little more practical.

Guirella Centre of Excellence

It's "reccomended best practice" these days to have a BA Centre of Excellence for any decent sized organisation, and most pieces of improving the performance of the BA function in an organisation being with getting senior management buy-in for starting one. This is fair enough.

But what if you can't?

I knocked togather a few powerpoint slides on low cost, cheap, fast ways to improve performance of the BA function in your organisation if you can't do anything formal. Essentially it boils down to:

• Encourage social contact amongst BAs
• Do information sharing at informal brown-bag lunches
• Have a good bookshelf on-hand
• Have conversations about basic theories, i.e. "What is a requreiment?"
• Use BABOK and IIBA to enhance the "professionalism" of being a BA

This all comes down to encouraging self-directed learning, and a team pride in the BA role.

Guerrilla BA CoE

View more presentations from harrislloydlevy.

Building Living Specifications

Producing new functional requirements for each project is evil and should be illegal, and punishable by death or working as a tester [1]. It is a basic cause of incoherent system, lack of holistic system thinking, and a lack of coherent documentation to support testing.

We've all had the experience of trying to understand the behaviour of a system and wading through reams of the original specification, change requests, and series of follow-on project specs, so why do we willing perpetrate this mess?

Probably a few main reasons:

1) The model of monolithic documents being prepared, signed-off, and developed against encourage this beahviour.
2) In the short-term it's the fastest way to get your individual project over the line
3) It's how we've been taught to do it
4) When we do decide to do something about it, we don't get angry that we're documenting badly, we get angry that we're documenting _at all_, and we implement some messy mix of agile and waterfall.
5) Wanting to have "all the information in one place" for decision makers (Which is a really valid point)

So what can be done about it? I'd generally propose a few changes that don't involve a massive change to current practices.

1) For new projects try to split out the project ephemera from the functional design that will be re-used.
2) Instead of having a singel plave for all project documentation, have a seperate place for storing project documetnation, system documentation, and process documentation. This reinforces that they should be treated seperately.
3) Gently ease into some business architechture questions, because if you're not using projects as the basic unit of information, you're going to need soemthing to replace it, and a system centric-organisation is a pretty poor substitiute.
4) Get some soom document/knowledge management systems. Shared directories will not work if you're moving towards lots of smaller documents. Consider Sharepoint as your first stop, and moving towards a Wiki and a Modelling tool in the long tem.

All of these mitigate against most of the objections I raised earlier, but they still don't give you the "single view" of the changes you're making for the project. Unfortunately there's no magic-bullet here. The more solution centric you make your documents, the less project centric they become.

Ideally you could mix-and-match content together into dynamic documents. But there's just no good tools for that, confluence is closest but really isn't there yet. There's a good summary of why up at http://confluence.atlassian.com/display/DISC/Using+Confluence+for+professional+documentation.

[1] Nothing against testers. It's just that most BAs hate working as testers.