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.
20 June 2014
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.
- The stakeholder owns the use case or is the authorised proxy of the owner.
- The use case is relatively atomic.
- 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.)
- 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.
- At the time you cannot identify any duplicated effort in producing the requirements.
- 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”.
Labels:
business,
business analysis,
development,
requirements,
systems
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.
- The User opens the “Hello World” program from the Start Menu.
- 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:
- The User initiates interaction with the System from an entry point.
- 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.
Labels:
business,
business analysis,
development,
requirements,
systems
Subscribe to:
Posts (Atom)