Archive for the ‘Requirements’ Category

Human Interactions in the English countryside

Thursday, July 15th, 2010

If you are interested in next-generation techniques for managing collaborative human work, you may like to know about a series of workshops on Human Interaction Management this Autumn.

I will be running them myself. Each workshop is limited to 8 people and the focus is on producing real-world, usable results. Attendees will come away with executable processes and organizational models based on their own business.

More details below.

Role Modellers Autumn 2010 Workshop Series - Human Interaction Management

“The first fundamental advance in personal productivity since the arrival of the spreadsheet” (Information Age, 2007) is here, and we can help you get started. According to Gartner, the “Fourth Wave” of Human Interaction Management techniques and tools won’t be mainstream until 2012 - so now is your chance to get ahead of competitors.

Located at Role Modellers’ offices in a picturesque English market town, this 2-day workshop is a hands-on introduction to next-generation process modelling and execution techniques that deal with human work at all organizational levels.

Working with examples from their own business, attendees will learn how to:

* Reduce knowledge worker costs by up to 75%;
* Deal efficiently and effectively with the 20% of “exceptional cases” that generate 80% of operating expenses (and potentially 80% of revenue);
* Build collaborative business applications in minutes;
* Implement true cross-boundary business processes;
* Define and execute organizational strategy.

Workshop Brochure: http://tinyurl.com/2ugrvh7

Posted in Business Process Management, Governance, Knowledge Management, Management, Productivity, Requirements | No Comments »

Forming a Business Change Team

Wednesday, March 11th, 2009

In my last post I began explaining the different high-level roles involved in the governance of business change, by focusing on Requirements Management - a role that deserves special attention since:

  • Requirements Management (as opposed to Requirements Gathering or Requirements Analysis) is widely misunderstood - or not understood at all;
  • Requirements are fundamental to any form of business change - get your requirements wrong and any related efforts are doomed to failure.

In future posts I will discuss the other high-level business change roles:

  • Stakeholder Management
  • Business Change Management
  • Benefits Management
  • Risk And Dependency Management
  • Marketing And Communications

First, however, some people have asked why all these roles are necessary.  To see this, it is necessary to backtrack and ask a preceding question: what are the goals of a business change activity?

You might think that goals would be different in every case, but in fact the key aims of business change are always the same:

  • To ensure that work meets stakeholder needs - for which you need to identify stakeholders, both internal and external, and communicate with them effectively;
  • To deliver results into a business-as-usual environment - the key purpose of a dedicated business change role;
  • To maximise benefits from outcomes - i.e., work out in advance what your benefits will be, and then ensure that the consequent work realizes these benefits;
  • To minimize the costs associated with delivery - which means managing dependencies and risks.

A little thought shows that, to achieve these goals, the Roles above are all necessary.  In some cases more than one Role may be played by the same person, but unless you start with an understanding of Roles and associated responsibilities, important activities will slip through the net and your work will not deliver the desired results.

TAKE AWAY

There are many different methods for handling business change.  For example, many consulting firms base their practice on a proprietary approach to business change.  However, none of these methods are grounded in a robust theory of human work (since the first such theory is Human Interaction Management, which only appeared recently).

In the end, all current mainstream approaches to business change are essentially a synthesis of carefully selected best practices.  The problem with such approaches is that it becomes hard to join all the dots - to connect high-level strategy with middle-management practice with operational activities.  Many business change activities appear to have succeeded but fail to deliver the expected results, since there are unforeseen breakdowns where the realities of human-driven process enactment do not live up to the expectation as depicted on colourful Web dashboards.

A key reason for this is Pareto’s rule: that the 20% of “exceptions” (which are really the rule, since they always occur) consume 80% of the costs.  To properly handle such edge cases, you need processes that have flexibility designed in - processes that do not pretend real life is as simple and mechanistic as a flowchart.

In harsh economic times, when cost reduction and improved effectivess is more necessary than ever, we need to get business change right first time - which means acknowledging this real-world nature of human-driven work.  We need a new approach to business change, an approach like the GOOD method associated with HIM (aspects of which I am describing here).

In future posts I will show the different areas of interest of each of the Roles above, and explain  how to develop a governance structure for your business change project, venture or initiative that ensures they collaborate effectively.

Posted in Business Process Management, Governance, Management, Requirements | 2 Comments »

Business Change Made Easy

Thursday, February 26th, 2009

My last post included a diagram showing the different high-level roles involved in the governance of a business change effort, and promised to explain more.  In this post I will discuss a role that is pivotal to success, yet almost always misunderstood - Requirements Management.

Ask a range of people to define Requirements Management and you will get a range of answers.  Some will say it concerns the management of a team of requirements analysts.  Others will mention maintenance of a requirements repository.  Many will talk vaguely about “engaging with the business”.

Only rarely will you hear anything about the true focus of requirements management, which is sustainability.  Anyone can run workshops and document a resulting set of “business needs”.  It is not even particularly hard to keep these documents reasonably up to date.  What is far harder is to ensure that your requirements are key to controlling business change - that they guide all the work carried out through all the life of an initiative, project or venture.

Achieving this requirements nirvana has several aspects.

For a start, your requirements repository must contain the right sort of artefacts.  The most beautifully constructed use cases and sequence diagrams in the world will not make up for there being no domain model (surprisingly often the case), process architecture, organizational structure, and so on.  Here it is not one size fits all - although certain information is always necessary, the degree of detail and appropriate formats vary from situation to situation.

Then there are scope issues.  What is the reach of your information and your interactions?  Have you modelled enough or too much?  How far do the tentacles of your requirements gathering and analysis stretch, and how should you deal with the boundaries?  More subtleties that take skill and experience to handle.

A different but vitally important aspect is how the requirements are used.  Here it is no good relying on informal interactions with colleagues.  However good your inter-personal skills may be, everything can - and will - go to hell if you don’t have formal processes to manage the flow of intent (which includes the flow of information but covers rather more).  Rely on goodwill and a single calendar clash, annual leave, change of position or accidental CC ommission may throw a small but fatal spanner into the works of a huge programme.

Further, like all forms of management, it is necessary not only to define goals and provide resources but to monitor the work carried out and adjust as necessary.  Requirements can be wrong, for a start, or simply need enhancement based on the in-depth experience of those charged with implementing them.  Further, requirements management is closely tied to other types of high-level management, as the diagram in my last post shows.  These demands make the need for formal, well-understood processes (as opposed to informal human interactions) even more vital.

The processes in question are, as regular readers of this blog will be aware, not the kind that can be described using flowchart techniques - rather they are the iterative, interactive, innovative kind that typically cross organizational boundaries.  To understand and describe such processes, you need the techniques of Human Interaction Management (HIM).

Orthogonal to all the concerns above are relationship issues - within the requirements team, with those who must implement the requirements, and with stakeholders both internal and external.  The best artefacts and the best processes cannot achieve their purpose if the people involved are mis-aligned.  Here again it is necessary to apply HIM principles - teams, communication, knowledge, time management and planning are all essential factors.

TAKE AWAY

In my last post I emphasized how transparency was the key factor in success of a business change initiative.  Many people find it hard to achieve this - the culture they are working within may discourage it, for example.  The way to solve such problems is not to make a general demand for “more open-ness” or any other form of deep organizational change, but to focus on intended outcomes - one by one.

This comes down to the aspects of requirements management discussed above.  Make a public case for each aspect in turn, via a formal document, using language that is simple and neutral.  Those above, around and below you - whatever their priorities or agendas - will find it hard to resist the simple logic of each small change to working practice.

Working softly softly in this way, you will eventually find you are where you need to be.  Look after the pennies and the pounds will take care of themselves, as they say.  Or used to, before the credit crunch :-)

Stay tuned for more advice on business change made easy.

Posted in Management, Productivity, Requirements | 2 Comments »

Strategic and Executive Control

Thursday, February 19th, 2009

In my last post, I described a framework that can be used to guide business change - the OMG’s Business Motivation Model (BMM) - and suggested that you also need other techniques in the early stages of an initiative, project or venture. In fact a tool such as BMM is only the start.

Any form of business change must take into account a number of varied factors, any of which can derail the effort if not dealt with properly:

  • Organizational structures both old and new
  • Dependence and impact on external supppliers
  • Perceptions both inside and outside the team
  • Timescales and associated resources
  • Risks and associated mitigations
  • People and associated interactions
  • etc.

To deal with all this harmoniously requires a clear understanding of governance. The methodology associated with Human Interaction Management distinguishes 2 forms of governance: how to set goals and stick to them (strategic control) and how to make the work fit into an organizational context (executive control).

Shown below are illustrations of the key governance roles:

… and of how these roles work both together and with lower-level roles for management control:

TAKE AWAY

In my experience, if there is a single key factor that distinguishes successful initiatives, projects or ventures, it is transparency. If everyone involved can see what is going on generally, they can understand their own part in it and make sure they are working effectively, safe in the knowledge that their work will be recognized. They can also help identify general issues as early as possible, and see why it is in their own interest to do so.

If, on the other hand, the waters are generally muddy, people go into back-covering mode. They work to rule, not only doing the minimum necessary but also spending valuable time proving that they have done so - time that would have been better spent making productive contributions. In extreme cases, in which there is little reason to believe that the work as a whole will succeed, people will devote most of their daily effort to saving their own reputations - much like a run on a bank that is suspected of failing.

In the next posts to this blog I will explain the pictures above, and show how the simple practices depicted help to ensure success both for the teams you work in, and for you personally.

(more…)

Posted in Management, Productivity, Requirements | No Comments »

Business Motivation Model

Thursday, February 12th, 2009

First an apology.  It has been over 3 weeks since my last post - and yesterday a commenter on that post wrote:

Great teaser, please, release the other posts of the new series ASAP :)

Thanks, Kerber, for the prod.  As an excuse, I’ve been very busy recently putting into practice the ideas I promised to write about!

Let’s start with a technique that has been around for many years now but is not as well known as it should be - the Business Motivation Model.  This is now an OMG specification (http://www.omg.org/spec/BMM/1.0), although it originally started life with the Business Rules Group, who were responsible for the key concepts.

The BMM fills a vital gap in the business analyst’s armoury.  Indeed, it is a technique that, in conjunction with the right supporting framework (which I will be describing in the rest of this series) is capable of elevating business analysis above the low technical concerns in which it is currently mired.  The BMM allows you to provide a formal basis for business change planning - not just IT system implementation but any form of initiative, project or venture. Indeed, a key benefit for IT people of using BMM is that it places the high-level focus directly on high-level business drivers, rather than on low-level technical concerns.

Surely, I hear you say, no modern development project would fail to take account of business issues - indeed, no modern development project would fail to put business issues firmly in the driving seat.  Here I must interject a hollow laugh.  Where projects have an IT element, most “high-level” documents purporting to address strategy, benefits, requirements, change planning, and so on are thinly disguised computer system proposals - the IT element hijacks and dominates everything else.  This may be because IT is more familiar territory to the people who draw up these documents, or because business analyis techniques often come from an IT world and are thus IT-oriented.  The end result, however, is that most projects that are IT-related become IT projects, and thus fail to deliver the full business benefits originally promised.

It is the responsibility of the business analysts who become involved at an early stage to remedy this situation - and doing so will have the pleasant side-effect of increasing their own credibility, since they will then become business change agents rather than factories for system architectures and program specifications.  Most business analysts of today are in fact “systems analysts”, which is not a healthy situation either for the business or for their own careers.

How does the BMM help?  It provides a metamodel with which you can capture the “ends” (vision, goals and objectives) of a proposed business change, together with the “means” to those ends - mission, strategies (with associated tactics), and policies (with associated rules) - and the “influencers” whose “assessments” drive, guide and control the work involved.  Simple but powerful stuff.  My own experience with BMM is that it provides just the right amount of rigour - enough to help understanding, but not too much to prevent flexible use in different circumstances.

You don’t need tools to use BMM.  If you use the IBM Rational Suite, there is a RequisitePro template for BMM available from IBM.  However, you can adopt the analysis techniques and document your findings using any word processor or spreadsheet.

TAKE AWAY

Despite the potential value offered by BMM to enterprises of all types and sizes, its take-up has been slow.  Some people find it confusing - there are feedback loops around Influencers and Assessments, for example, and it can be hard to retrofit BMM to existing projects.  The lack of good explanatory documentation does not help here - and in general, the OMG could do a lot more to encourage adoption of BMM.

There is also a deeper concern about incompleteness.  In my own work, I use BMM as an element of the GOOD methodology (see http://human-interaction-management.info) to provide a route to action and integrate multiple change planning efforts.  In future posts, I will say more about the other techniques that you need in order to put BMM to best use in the early stages of an initiative, project or venture.

Stay tuned, and I’ll try not to leave such a long gap before the next post ;-)

Tags:
Posted in Career, Management, Requirements | No Comments »

Derisking Software Development via Business Modelling

Monday, January 19th, 2009

As a consultant I often advise large-scale software development projects that have got themselves into trouble, or fear they are about to.  The root causes are wide ranging, but more often than not, the problems arise from mistakes and/or omissions very early in the development lifecycle.  This is such an old story that one has to wonder - why have people not yet learned that a stitch in time saves nine?

The answer, I believe, is that mainstream approaches to the software development lifecycle still lack mature techniques and accompanying tools in the early stages.  For example, even when a project makes an effort to construct use cases they often turn out to add low value.  This may partly be because use case design has been stripped of entity modeling aspects included in its original formulation, aspects designed by Ivar Jacobson to help ensure the viability of use cases.  However, a deeper reason is that current techniques used early in the development lifecycle are incomplete.  We need more than better use cases - we need more than use cases per se.

Despite dramatic improvements in the last few years in many aspects of software production, such as the emergence of agile practices (including practices associated with iteration such as test-first coding) and higher-level code generation techniques (ranging from programming tools such as “model-driven architecture” to systems for process and rule definition), there have been only minor improvements to the way in which people understand the business drivers that cause software to be constructed in the first place.

For example, consider Rational Unified Process (RUP), which thanks to adoption by IBM is one of the most widely used software development methodologies.  Proponents of RUP claim that it is an almost universal technique, offering support for iterative approaches despite its traditional waterfall origins.  RUP has given rise to an “open” descendant, Open Unified Process (OUP) which is also touted as being adaptable to pretty much any software project.

RUP and OUP place particular emphasis on the early stages of a project, with “Construction” being deferred until the third of four phases, and practitioners being encouraged to use structured disciplines for Business Modeling and Requirements Analysis.  However, dig a little deeper and the picture starts to develop cracks.

In particular, the “Inception” phase of RUP is supposed to include development of a “business model”.  What exactly is a business model?  Well, who knows - certainly, there is little in RUP itself (or the accompanying IBM toolset) to explain the term.

The main clue is mention of “business” use cases, as opposed to “system” use cases.  This is a useful distinction, but not a very clear one, and does not go anywhere near far enough.  Where are the business objects of primary value identified, their lifecycles described, their stakeholders defined, and the interactions between these stakeholders captured?  Where are the drivers for high-level system strategy, and the mechanisms for implementation of this strategy?  How are domain security models to be understood and related to user experience models?

TAKE AWAY

Mistakes and omissions made early in a software development project are always the most expensive sort.  Unfortunately, they are also by far the most common sort.

In this new series of blog articles, I will be suggesting ways that you can improve the early stages of the software development lifecycle, by reference to the business modelling techniques of Goal-Oriented Organization Design (GOOD).  GOOD was created as a methodology to assist implementation of Human Interaction Management (HIM) techniques and tools - and a key driver for HIM itself was innovation in requirements analysis (see the HIM Web site for details).

If you are interested to learn how business motivation modelling, process architecture, organizational design, edge stories, user profiles and classic scenarios can help you capture and analyse requirements more effectively, then stay tuned to this blog.

Posted in Requirements | 2 Comments »

Reduce Software Project Failure Rates by Capturing Human Interactions

Tuesday, April 8th, 2008

Recently I have been doing some consultancy work around requirements analysis - in particular, for a large project that decided halfway through to postpone a large swathe of requirements until a later stage.
This move, intended to reduce risk, in fact replaced one set of risks (that the requirements could not be implemented as intended) with another set of risks (that the resulting system was not fit for purpose). Hence I have been attempting to de-risk the project by analysing the implications of the move - not only on users of the initially delivered system but also on the project itself at a later date. It is quite possible that, in order to deal with the absence of certain capabilities in the short-term, it may be necessary to introduce design features into the technical architecture that turn out to prevent successful retro-fitting of the missing capabilities later on.
This heart of this work is to analyse the patterns of behaviour that humans will adopt to work with each other via the system. As a result, it has an interesting synergy with a paper I wrote a few weeks ago, for the Requirements Networking Group. Here is the abstract from the paper:

In the end, software applications are only there to support human work. Even a low-level, highly automated software application for (say) car numberplate recognition or payroll calculation is only there to meet the needs of the police officers or HR staff who ultimately set its initial parameters and use its output.
Yet most approaches to understanding and modelling human work have a major weakness - they offer reasonable support for capturing H2S interactions (between humans and systems), but are extremely weak when it comes to capturing H2H interactions (between humans and humans). Further, mainstream modelling techniques provide little of the context required to understand what truly goes in knowledge work.

You can find the paper online. You have to join the RNG to access it, but membership is free.
TAKE AWAY
It is really quite startling that issues such as the above are still a problem for software requirements analysis, when you consider how fundamental an engineering task it is.
As another illustration of the immaturity of this aspect of software development, the open source movement is only just waking up to the need for a general requirements management framework (see Open Requirements Management Framework aka ORMF) and an enterprise-oriented application development framework to encompass it (see Open System Engineering Environment aka OSEE). Both these frameworks are only just getting off the ground.
Have you ever noticed how a root cause of software project failure lies in poor requirements engineering? If so, you may like to read the paper referenced above, and check out ORMF/OSEE for yourself.

Posted in Requirements | No Comments »