Skip to main content

Author: Keith Ellis

What is Requirements Maturity?

KeithEllisBlog_Dec14_croppedWe’ve been in the business of helping companies improve their requirements definition and management (RDM) maturity for over 13 years.  One thing I’ve noticed is that companies that have made significant improvement in RDM tend to believe they are operating at a higher level of maturity than they actually are. There’s a tendency to beat the chest and sing the praises of organizational excellence in RDM, when the reality of project performance and efficiency speaks otherwise. There are really two issues:

  1. Every organization has blind spots – people focus on what they do very well and tend to stay focused on these issues to try to spur further improvement. As counter-intuitive as it sounds, this doesn’t work in RDM and you get a false sense of continuous improvement. In RDM, you have to find the blind spots, the stuff you don’t do well, and fix those to really make gains.
  2. People define RDM “maturity” in different ways, either narrowly describing it <<>> as merely having a stable documentation template that is used across the corporation, or more properly, a unique process within the organization that is defined, resourced, and supported.

So, simply – what is RDM maturity?  Process Maturity is all about the degree to which an organization can be repeatable, consistent and efficient in execution on a process – same thing with RDM.  Organizations with no defined process, or a process that is defined but not enforced, would have low levels of maturity, just like organizations with well described, institutionalized and optimized process would have high levels of maturity.  The issue is that it is not just process you need to look at, there are six underlying capabilities:

  • Process – What people need to do.
  • Technique – How people will do various steps in the process under certain variations and conditions.
  • Staff Competency – The skills, roles, functions of your people and their alignment to this target currently and in hiring practices.
  • Tools/Technology – The support and automation used to complete tasks.
  • Organization – The framework of doing requirements, infrastructure backing it, the services offered to the organization, and approach to managing resources.
  • Deliverables – The actual artifacts, deliverables and work products needed to make the process work.

Here is where most people fail…  they don’t look at ALL the underlying capabilities.  An example organization might have well defined process and deliverables, but a terrible definition of the staff competencies needed and little training and support to build these capabilities.  How effective is this organization going to be if they are essentially defining what they want people to do, but not giving people the skills to perform those tasks?  If you believe yourself to be a high maturity organization, look across all six capabilities – which is your weakness?  That’s the one you need to focus on.

The other mistake people make is in thinking of requirements as only documentation, or only elicitation.  In fact the “process” of requirements is made up of a number of really important processes like:

  • Requirements Planning and Management
  • Requirements Elicitation (requirements gathering)
  • Requirements Analysis and Documentation
  • Requirements Communication
  • Requirements Implementation

In reality, and organization may think it is very good at one or two of these process areas, and therefore consider itself mature, but few organizations look across all the process areas and understand their strengths and weaknesses. Again, just because you are great at one thing, does not mean the entire process is particularly efficient or predictable, and that means that it cannot be considered mature.

Getting maturity in your requirements organization might sound complicated, but it’s really all about being honest with yourself in looking at the organization and accepting that there are always areas of improvement.  Most of the time, these improvements are in areas that the organization does not see – it’s blind spots – so often, it’s necessary to bring in outside people to assess the organization… just like you would with auditors.  So organizations often go around thinking they have a more mature organization than they actually do… and they miss out on the benefits thinking there is limited room for improvement.  On the upside, high maturity organizations have exception on-time, on-budget, and on-function performance – they also tend to deliver applications at about 40% of the cost of their low maturity competitors.  I’m wondering:  what other investment in IT yields so much just from being very frank with yourself?

Don’t forget to leave your comments below

Swamped in Detail

In the world of requirements – How much is enough?  While this might seem like a bizarre question to attract vehemence to anyone outside the profession, it’s certainly a question that will incite the opinionated and the pundits to stand on a soapbox and rant.  To me, the whole debate is a red herring that can be argued from any angle since everyone’s business context will be different.  If one team is looking at selecting and implementing a large commercial application, the business context for requirements are very different than if another team is doing smaller maintenance activities:  my suggestion is the structure and purpose of requirements is far more important.

Let me prove it to you…

Imagine yourself at a buffet – the largest in the world if you will.  Every dish imaginable, made with impeccable care and attention to detail. Now imagine it’s all in one gigantic bowl…  Now all of a sudden all that attention to detail is a lot like eating out of a dumpster – not really appealing.  However, this happens all the time, people focus on the wrong type of detail at the wrong time but generate huge volumes of information.  If the structure is wrong, if you can’t connect the critical functionality back to the basic business processes, you might as well through it away.  You can spend millions trying to generate requirements, but without careful consideration to what kind of information needs to be generated, those millions can be wasted; you end up with a whole lot of not particularly useful information.

Let’s talk about the purpose of requirements…

Should you generate the same structured set of requirements when doing, for example, the purchase of an application as when you do an offshore build of an application?  Most BAs and project managers reading this will say ‘absolutely’…  most businesses actually doing the activity radically change the structure and approach to doing the requirements when they change the type of project.  My view:  this is why so many millions are lost on failed projects.

Here’s a thought:  the basic structure and approach to requirements should never change for any application that transacts a process…  ever.  What changes is the purpose of the requirements and how you situationally align detail and documentation to that purpose.  For example, if you’re doing an RFP for selection of an application:  do the requirements exactly the same as always, and add to it, the evaluative and vendor management detail.  If you are doing a design/build/offshore:  do the requirements exactly the same way, and add to it, the incremental detail of architecture, system interface, GUI, and greater elaboration of functional/non-functional process.  How much detail is enough?  Well, it depends on the situation and purpose of the requirements -e.g., what do the interdependent and downstream stakeholders need to do with the requirements, and in what format can they best use the requirements, and how adept are they with requirements, and how can I best format this same basic set of information to meet their needs?

Companies sometimes get too smart for their own good – people over think the requirements process just because they have a project that is substantially larger or more complex and they make a radical change, sometimes leaping into something that is relatively unproven in approach.  Candidly, the requirements process should be boring – always the same way, all the time.  Another word for this would be ‘consistent’.

So how do I know I have the right level of detail?

Well, if you follow my advice:  the right level of detail is found ONLY when:

1. you’ve followed a consistent framework for doing the requirements that is considered best practice for your organization; and,

2. you’ve assessed the needs of the recipients of the requirements and both framed the requirements information into a format that is easily used by these recipients, and added to the information sets necessary for that those recipients to perform their tasks.

Don’t get caught up in the trap of debating detail as a standard – it’s a trap.  Keep the framework consistent, and let the level of detail be driven by the purpose and form of the requirements – i.e., Let detail be driven by what is useful, not for the sake of doing it.  This means that Effort is now better tied to Utility … so long as a consistent framework of action is followed.

My suggestion…  don’t get swamped in detail for the sake of detail.  Have all the information that is necessary and sufficient to the purpose, and a form that is optimal to the usage…  You may actually find yourself eliminating detail that distracts from the purpose and usage of a document – and gain something that communicates business need far more effectively as a result.

Nomination for the Most Misused Word in IT Projects

Every industry has its own language … just like every industry has a set of marketers out there just itching to bastardize that language.  It’s a situation that leads to all kinds of confusion which, in turn, leads to all kinds of sage consultants able to charge all kinds of dollars to sort the situation out and keep the great wheels of commerce churning.  The technology industry is built, to some extent, on bafflegab, trends, fads, and on some outright goofy ideas turning into mainstream approaches.  This is the good stuff that keeps the industry dynamic, entertaining and employing so many of us as the pedants argue about whose cloud is whitest. 

It’s the more mundane misuse that’s insidious.  You’ve seen it in meetings:  two people in the same meeting talking about the same thing and using exactly the same words yet having exactly the opposite meaning.  Business analysts should have written for Abbott and Costello – only instead of “Who’s on first”, we ask something innocent like “What’s an order” … and watch the conversation go.  Let’s face it, communication is wonderfully imperfect.

Personally, I’d like to nominate the word ‘scope’ as the most misused word in IT.  Every project has it, ask anyone about a project and they know it, and you can over-, under-, de-, re-, and add-just-about-any-other-adjective-in-front-of-it… scope!  Scope also tends to mean something entirely different to everyone in the room:  to a business person, it’s often synonymous with ‘objectives’, for the developer its modules of code, for architects its more portfolio focused.  The difficultly is that the word scope means something different to every stakeholder group.

The biggie is the difference in meaning between project managers and business analysts – they are just not the same thing.  For project managers, scope encompasses the project from inception to implementation and has charter through implementation tactics.  For business analysts, scope means something entirely different; it’s the ‘scope of analysis’ or the breadth of functionality they need to analyze to determine the business requirements. Candidly, it is not the same thing even though analysts like to use the same word.  Just because the project manager knows the scope, does not mean that the breadth of work required of analysts is particularly well understood.  This error leads to all kinds of problems for the business. One of the biggest is not setting aside a discrete step in many project management approaches to actually determine this through a requirements planning activity.  Kudos to PMI – they recognized this in the new PMBOK.

Language has all sorts of fun twists, most of which just need to be discussed so you get to a common understanding.  It’s when the disconnect gets engineered in to the way companies work on an ongoing basis that it creates problems.  So my vote is for “scope” as the most misused word in projects today.

What’s yours?

Don’t forget to leave your comments below

The Fine Art of Complaining

I think complaining is an art form.  There should be scores of admirers and Oscars awarded to honor those who are truly gifted complainers.  Being an executive for so many years, I’ve had the privilege of being on the receiving end of a great deal of complaining over the years, so I consider myself something of a connoisseur on the subject;  I also have tremendous respect for the folks who get it right.

First off, you need to separate complaining when your rights or company policy are violated versus everything else.  If you have a rights issue like harassment, then your path should be to keep the description of the situation simple, keep it objective, keep the documentation of the incident(s) organized and escalate it through the right channel (HR, your boss, the police, etc).  I don’t consider this type of thing ‘complaining’ – it’s more like ‘reporting’.  In fact, when dealing with this area, ambiguity clouds the issues, so you want to make sure the report of the incident(s) is as concise as possible, so people don’t get sidetracked with distracting and possibly irrelevant information.  This situation sucks, but sometimes has to happen.

It’s complaining about everything else that lends itself to artistic expression.  The absolute masters of complaint don’t really come across as complaining.  These folks are generally very positive in outlook and frame up the issues in a way that aligns what they’re trying to achieve, clearly, with what is in the best interests of the company.  It makes the issues very easy to understand.  What makes it even easier to bridge the gap between simply understanding and being motivated to take action, is when it’s clear that a positive outcome will be achieved by making change.  I love these folks as employees, customers and suppliers because dealing with one of their complaints gets the company to a positive outcome.

I even enjoy the folks who really try to frame up situations in positive and constructive terms that are kind of goofy.  “Upgrade the laptop because we want customers to see that we’re a really successful company.”  No, but I’ll give you points for pitching me the idea this way.  Some of these are hilarious – you probably have one or two stories.  Once in a while, I’ll even buy into the argument.  I’ll even give a lot of latitude to folks that seem to totally lack a sense for setting context – you know the type… it’s like they’ve been arguing with themselves for an hour, then only tune you into the last 30 seconds.

The folks who are depressing to deal with, are the ones with a negative outlook.  Frankly, with these folks it’s tougher to separate the issues from the desired outcome, from the negativity, on real concerns.  It’s all muddled together.  I might even have a candid desire to help, but sometimes the negativity taints my perception of their personal agenda and makes me more circumspect in action.

I think we need a set of golden rules for complaining. Help me educate folks on your best techniques.  Here are five of mine:

  • Be objective and de-personalize. Personalizing something will immediately set off an executive’s listening skills and start them down the path of explaining why you need to work better with your colleagues (pretty much the opposite of the outcome intended from the complainer’s perspective).
  • Make your personal agenda clear. This is your context. If the context is fuzzy, then people are left guessing.
  • Sometimes there is just no answer to ‘so what do you want me to do about it?’ in all the words streaming in your direction, which, in my opinion tends to comes across as lazy on the part of the complainer, especially if it’s any part of their job to come up with solutions.
  • Be clear on what you can accomplish in under eight minutes. The average executive deals with an issue in eight minutes or less. The onus is on you to package up the issue to either deal with it in under eight minutes… or plant some seeds so you get a more efficient conversation some other time. Pick one…
  • Be positive and frame up the issue as an opportunity to improve terms – even if doing this grates on you the wrong way.

Hey, sometimes I’m cranky and need somewhere to vent for the sake of downloading.  But remember, if change is really the goal – and the goal is not to complain for the sake of complaining – then focus on how to position your words to best achieve that goal.

Suggest your own golden rules. Or suggest some situations and let’s talk about how to frame things positively to get change.

Don’t forget to leave your comments below

The Pendulum Swing of Organizations

I wonder if organizations give out awards for surviving the most reorganizations in a single decade to particular business functions.  I’m thinking that most analysts get to experience this frequently as the pendulum of organizational design swings from housing analysts in the technology organization, in the business organization, centralizing or decentralizing.  As business reorganizes, technology changes alignment, and the moon aligns with various constellations, reorganization is triggered.  I’ve been asked to weigh in on this a bunch of times.  Here are some thoughts for whoever is gunning to get the new design in place for September.

There are Lots of Designs that Work, but Very Few Organizational Designs Promote the Goal of Improvement

If you have a team of BAs, you can organize by application, by business, by seniority, by type of BA, by geography, then you can organize management centrally, or by business line, or by matrix of business and IT, or … and the list goes on.  All designs are for a reason, so they will all accommodate some aspect of the culture or gap or improvement, or machismo that needs to be addressed.  Only some designs will promote the goal of improvement in the capabilities of BAs and consistency of service brought by BAs to the organization.  The designs that best enable improvement bring together and optimize three basic areas:

  • The Framework: What are the processes, practices, tools, metrics, deliverables and standards etc, of doing requirements?
  • The Resources: How are the competencies defined and managed, how is performance managed, and how are resources allocated to work?
  • The Infrastructure: This is the governance, business alignment, organizational integration k, etc.

The more fractured these things are, the more difficult to manage and promote standards and change. By the way, improvement may not be the primary organizational design constraint and sometimes you need to work with a suboptimal organization structure to enact change.

A Few Pointers 

Even when you have a poorly designed analyst organization, there are a bunch of things that can be done to make it function better. 

Centralize Analyst Work Intake. Even if the organization is a complete mess, centralizing the small function of estimation and work package creation pays massive dividends, especially when the analyst organization is larger.  And, it’s not expensive.

Think Services.  Sometimes it is not possible to get centralization on the entire analyst organization, but it is possible to get an institutional focus for a small set of high-end services, especially when these services are directed at success for larger projects.

Revise the Hiring Practices. I’ve come to the conclusion that a lot of companies don’t really know how to hire BAs.  I think people don’t realize it’s a tactile job, yet a lot of companies hire without seeing how a BA does these hands-on things.  It’d be like hiring a nanny without ever checking out how they interact with the kids.  I’m not talking about charisma or being personable here, I’m taking about aptitude and the ability to ‘do through interacting’.

Right-size the Organization.  One of the biggest oddities is the vast differences in size of the analyst function at different organizations.  Sometimes one or two BAs are driving $100M in projects, sometimes it’s over 100.  When you get way too few, the organization get really ineffective because all the people can do is be traffic cops and oversee the outsourcing of work.  When you get too bloated, the work progress slooooowwwwssssss waaaaayyyyy dooooowwwwwwwnnnnnnnnn; it’s painful to watch.  We get people that are used to taking a week to deal with what we deal with in a day – it’s really hard to reset expectations.  It’s not difficult to do know the right number of people, but hiring headcount is often difficult to deal with.

Be Positive and Patient. There is a time and situation when changing the structure of an organization  becomes dramatically desirable.  There are also times when no amount of executive discussion will create openness to change.  As anyone paying attention to the recent financial fiasco knows, external influences can create a 180 degree change in focus extremely quickly.  Timing and planning are everything, as are planting seeds for change … sometimes for years.  Remember, eventually, most companies try to do the right thing.

Don’t forget to leave your comments below