ben.eficium is the blog of Ben Slack, citizen and principal consultant at Systems Xpert.
All posts are Copyright © Ben Slack on the date of publishing.

20 June 2014

Can you hire a "change agent"?

A lot of people seem to think you can. There are always ads on SEEK for an experienced "change agent". Often they are for 3-6 month contracts.

I know it's nearly a decade since I took the "Managing Change" elective in my MBA study, but introducing new work systems hasn't changed that much. All the literature at that time, which was around the beginning of the movement, made absolutely clear that a "change agent" is someone who has been in the orgainsation a long time, has the respect and admiration of colleagues and the political clout to influence and coerce decision makers. If you think a new contractor who'll be there for 6 months can do that, then you are out of your tiny mind.

You can hire a change manager. A change agent needs to be found inside the organisation.

18 June 2014

Abstract your requirements up-front (Part 2)

Due to a host of reasons including politics, budget, time or project owners' lack of experience, creating an abstract Use Case Survey (or other expression of abstract requirements) as a first step may not be possible

Every requirements analyst has been in a situation where before or during a meeting a stakeholder gives you, in the example of software, a detailed user journey and even screen mock-ups of how they want the software to work. They think they've done the work for you. An abstracted view of the requirements and use case development is not required. I say this is fine and useful in situations where the following conditions are met.

  1. The stakeholder owns the use case or is the authorised proxy of the owner.
  2. The use case is relatively atomic.
  3. The work provided is obviously correct or mostly correct. (If it's only mostly correct, you need to weight the cost/benefit of the battle to improve it.)
  4. The inputs and outputs are controlled by the owner or the owner has the authority to speak for those who supply the inputs and rely on the outputs.
  5. At the time you cannot identify any duplicated effort in producing the requirements.
  6. Delivering the product is cost-effective.

I'd encourage you to make these points a checklist and mark against it when the situation arises.

Mostly these conditions are not met. You are presented with the “customer is always right” problem. Many experts say you need to follow the dictum to the letter. I've heard an academic say (to paraphrase), “Deliver the request, regardless of the consequences”. This doesn't work in the real world.

The needs of the project stakeholders are your primary concern. However, remember you are a professional. This stakeholder wouldn't give detailed instructions to a lawyer on submitting a statement of claim or instruct their accountant on the method of depreciation to use.

Business analysts may not have a state sanctioned professional organisation like the Bar or Institute of Chartered Accountants; however, you still have similar ethical obligations to your project stakeholders. If you receive a request which is unrealistic, inefficient, impossible or just plain stupid, you have a professional obligation to inform the stakeholders of this fact and recommend an alternative course of action (in writing if at all possible). Otherwise you are not a business analyst, you are a clerk.

In my opinion you are also under an ethical obligation to explain why the first step of system creation needs to be producing abstract requirements, use cases or any other method you prefer. Doing this in writing is important, if only to cover your own arse.

There will always be people who will ignore your advice, cut you off during an explanation, treat you like a clerk and demand the project be performed in a wrongheaded manner. If these are your clear instructions after performing your ethical duties to your best effort, then go ahead and do what's requested. When it all goes pear-shaped, don't be afraid to say “I told you so”.

10 June 2014

Abstract your requirements up-front (Part 1)

In my experience the best systems are created with methodologies that include the “use case”. In the Unified Processes, the central tenet of the use case method is recording an abstract description of the use case scenarios. In one pithy aphorism this means:
“A Use Case scenario must describe the interaction between a user and a system in terms of inputs and outputs only.”
There must be no detail of the exact physical actions required to enter inputs and receive outputs. In a software project, no descriptions of GUI elements; clicking on buttons, typing in text boxes, no dialog windows appearing, etc. In a purely human process, nothing as detailed as “wrap a product in bubble-wrap”, “give a PowerPoint presentation”, etc.
How many use cases have you seen that steps out scenarios that concentrate on physical actions? E.g.
  1. The User opens the “Hello World” program from the Start Menu.
  2. The System displays the introduction screen with a menu listing “X”, “Y” and “Z”.
These are not abstracted requirements. This is a written GUI design, which is pretty redundant, you may as well just do the screen mock-ups or workflows in Visio. A better use case example would be:
  1. The User initiates interaction with the System from an entry point.
  2. The System provides the User with options to continue with this Use Case (go to step 3) or perform other Use Cases (initiate new Use Case).
The point of this abstraction? Who's to say up-front that presenting a menu is the best way to do things? You haven't yet thought about: how this affects other related use cases; if it's consistent with presenting options in the other use cases; whether users will find this approach intuitive; if it's appropriate for every class of user, etc. The problems are multiplied in a large project with a team of analysts producing the Use Case Survey.
Producing an abstracted Use Case Survey for a project iteration allows designers to:
  • better avoid duplicated effort by identifying common aspects of system parts;
  • up-front identify the high-level duties of required actors, allowing managers to earlier prepare personnel (and unions) for changes in roles, responsibilities and job descriptions; and
  • most importantly, forces concentration on the purpose of the system as a whole; the “why and what” rather than the less important “how”.
The project as a whole will save time as producing workflow diagrams and screen mock-ups is more intensive work than writing a few simple use case documents. If you've planned better up-front, less tweaks and changes are going to be required for those graphical tools.
And these are just the benefits I can think of in the time it takes to write a blog post. Abstracting requirements up-front is well worthwhile. Do it every time you can.