Effective requirements collection, management and traceability plus smart PM practices equals project success.

About this Blog


Recent Posts

Caution: Agile Surface May be Hot

Organizational Change Management: The Most Critical Requirement of All!

Rethink Requirements: The Natural Language Processing Approach

Quality - Consider it in all Knowledge Areas!

Don't get COT[s] by your package!

Caution: Agile Surface May be Hot

Most people are familiar with the Agile Manifesto and its Principles developed in 2001 by seventeen people engaged in the IT (software) industry. Requirements take the form of a Vision Statement, Epics, Features and User Stories. Agile is much loved by those who like simplicity (does that include you?), high user involvement, high visibility of work to be done and work in progress, continuous team collaboration, self-managed teams, minimal documentation, face to face communication and very fast turnaround of deliverables in pre-planned, fixed iterations, creating a project cadence that raises expectations for frequent showcasing of completed work.

You may concur that sixteen years is a very long time in the software industry. I suspect Agile approaches are already baked into many methods. There has been talk and action for a few years now to make Agile scalable to deal with large projects, and hybrid methodologies have appeared that take advantage of the best of Agile and the best of traditional and iterative approaches. I believe there is wisdom in this thinking - something about not throwing out the baby with the bath water.

But Agile was clearly meant for software projects. Can it be used in non-IT projects?

A recent rather unscientific poll I added here seems to prove that one of the Agile frameworks, Scrum, is sufficiently pliable that it can be used outside the software industry. About 1/3 of the respondents (OK - only 21 responded, but you can change that), said they had used it on non-IT projects already and another third said they were planning to do so.  And there are plenty of industry posts about this. One of which I am particularly fond is by InfoQ, where they highlight some of the challenges with using Scrum on non-IT projects and provide some clues about how to convert from technical software terms to business terms.

I believe any project can benefit from Scrum methods. Who would not want to reap the benefits of high visibility of work to be done, progress being made, frequent communication, an engaged team and client, and work being presented in weeks instead of months or years? Wouldn't everyone want work to be broken down into chewable chunks when it is possible to do so? Remember what our friend Albert said: "If you can't explain it simply, you don't understand it well enough."

Maybe it is time to create an Agile Manifesto for non-IT business projects. What might it look like? I'll go out on a limb here to take a stab at it:

  • Individuals and interactions over complicated methods and software tools
  • Completed deliverables over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Okay - so what changed? Not a lot, really. I changed "processes" to "complicated methods" and "tools" to "software tools" in the first line; "software" to "deliverables" in the second line; and I didn't change the last two at all.

I chose the word deliverables since it is generic and could represent a process, a document, a change in the thinking of a group of people, a new product line - you get it - a business-focused item.

So we might think much of the change would be in the Agile Principles. As they say, the devil is in the detail, which is what the principles start to address. Let's take a shot at modifying those to be more business-focused and less software-focused:

  • Our highest priority is to satisfy the customer through early and continuous delivery of usable deliverables.
  • Welcome changing requirements, even late in deliverable development. Agile processes harness change for the customer's competitive advantage.
  • Produce deliverables frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people, subject matter experts and deliverable-producers must work together daily throughout the project.
  • Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a project team is face-to-face conversation.
  • Credible and usable deliverables are the primary measure of progress.
  • Agile processes promote a sustainable pace. The business people and the team should be able to maintain a constant pace indefinitely.
  • Continuous attention to excellence and good deliverable design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best work emerges from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Once again, not a lot has changed. Software becomes deliverables and some of the more technical terms are converted to more business-friendly terms.

Have you used Scrum on non-IT projects? How did it work for you? Did your business users embrace it? Was the high visibility too much for them? Did the team manage themselves? How was the business user interaction? And perhaps most importantly, were business requirements satisfied?

Weigh in with your thoughts!

Posted on: May 25, 2017 10:53 AM | Permalink | Comments (13)

Requirements That Make You Laugh

Have you ever run into a dangling participle or an object/verb mix up that made you laugh as you were reading requirements documents?  While this may be funny at the time, it can lead to some very serious consequences at other times.

For example, I once saw this requirement:

"The officer holding the handheld device must be able to plug into the USB port of the computer in order to charge the unit and transfer data."

When I read it, I did a double take, and read it again.  Now, we all know that the handheld device had to plug into the port, but really?  Grammatical rules tell us the officer would be plugging in, not the device, and ... well... I don't even want to go there!  Was it a simple typo?  Or was the person writing this in a big hurry?  Or was grammar and sentence structure not their strong point?

I'm sure I have made plenty of grammatical errors in this and past posts, so I am steeling myself for the result, but I am willing to take the risk!

So here is my "ask" as they say in the Telecom industry:

Have you run into any hilarious sentences in requirements documents?  Or have you run into any that were misunderstood up until the time of user acceptance when no one found it funny?

Post your responses here!






Posted on: January 28, 2016 03:04 PM | Permalink | Comments (17)

PMI's New "Requirements Management - a Practice Guide" - Another Layer of the Project Foundation

The newly minted “Requirements Management – a Practice Guide” from PMI has been available for free download for a few weeks now.  Have you downloaded it?  If so, what do you think? 

The Core Committee spent a lot of time and effort to produce it, so we owe copious amounts of gratitude to them, and the twenty-eight content reviewers, the PMI Standards Program Member Advisory Group and the three production staff. 

If you haven’t already downloaded it, click here.

You’ll find that this 56-page guide (not including the index and appendices) is written in a familiar way with textual descriptions, contextual and activity diagrams.  As stated in the introduction, this new guide serves as a bridge between the PMBOK ® Guide and the recent Business Analysis for Practitioners: A Practice Guide. The PMBOK Guide addresses good practices for requirements management, and the BA for Practitioners Guide describes what a BA does and how to apply requirements development and management skills to project tasks.  Intended for PMs and anyone doing requirements work, the Requirements Guide defines processes for requirements development and management.   

What is a Requirement? According to PMI, it is “A condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.” 

Requirements Management is about establishing a baseline and then ensuring it is traced (did the project implement everything it was supposed to?), managed through change control (if anything changed from the baseline, was it done in a controlled and approved way?) and updated (did the desired product, service or result of the project change, and if so, were the requirements related to the change appropriately captured in a new baseline?).

Requirements Development involves eliciting and identifying requirements, planning, analysis, documenting, specifying requirements and the necessary validation and verification.

The activities described in the Guide, paraphrased:

  1. Needs Assessment – Identifies the business problem or opportunity at a high level – normally before a project starts, but could be examined again if the situation changes before the start of the project or during the project.
  2. Requirements Management Planning – Part of the plan for how the project will be managed (the “Project Management Plan”, this describes the activities that will be carried out for the overall approach to requirements development and management.
  3. Requirements Elicitation – The drawing out of information from stakeholders to ensure a solid understanding of business needs, and to gain some idea of how the solution should address these needs.
  4. Requirements Analysis – Breaking the business needs down into requirements that fulfill the goals and objectives and can be actioned.
  5. Requirements Monitoring and Controlling – Ensure requirements end up in the solution and that any changes to requirements are made only when approved.
  6. Solution Evaluation – Validation that the solution meets the expressed business needs, and possible identification of new requirements that could lead to future refinement or new solutions. 
  7. Project/Phase Closure – Transition from a development state to a state off maintenance.

As you might expect, the Guide describes all interactions with the five Process Groups and ten Knowledge Areas.  The types of requirements defined are probably familiar to most people – those required by the business, usually expressed at a high level, those required by stakeholders, solution requirements, both functional and non-functional, transition requirements, project requirements, quality requirements and program requirements.

Techniques for eliciting requirements are also in the guide, comprising interviews, workshops, focus groups, brainstorming, questionnaires/surveys, analysis of documents and interfaces, prototypes and observation.

The Guide tells us that good requirements are unambiguous, consistent, correct, complete, measurable, feasible, traceable, precise and testable.  In an adaptive life cycle, they must be independent, negotiable, valuable, estimable, small and testable.

It also delves into backlog management and prioritization, and various models, including Scope (context, ecosystem, goals/objectives, features and use cases).  It discusses functional decomposition and feature trees, and various process models (process flow, use case, user story) and rule models (business rules, decision trees/tables), and a favorite of mine, data models (ERDs, data flow, data dictionary and state diagrams/tables). 

The Guide draws our attention as well to interface models, that is, what occurs between systems and/or users, considering report definition, flow of data between systems, user interfaces, and tools like wireframes, and the tabular N2 model.

There is much value to be found in this Guide.  I’ve only very briefly touched on bits and pieces of it here.   Armed with it, the PMBOK Guide and the Business Analysis Practitioners Practice Guide, a project team can’t go wrong when it comes to translating business needs to appropriately detailed requirements that can be traced, confirmed and verified - and, of course, translated into that infamous product, service or result required by the business.

Go get it while it is still free!

Posted on: January 14, 2016 09:29 AM | Permalink | Comments (9)

Data-Driven Requirements Gathering

Early in my career I was fortunate to have a mentor who was very data driven.  He believed that data in its purest form would help describe the processes that you might want to implement in a system, but that process analysis alone would not properly define the data and in fact, might very well define it improperly due to the usual insular aspect of looking at some processes and not all, of necessity given scope and budgets.

When I think about this at a high level in terms of typical data entities and processes, I have to believe that the metrics would support such a conclusion.  If we look at any particular organization, the number of processes operating on the same, similar or related data will be very high, yet the number of entity types the organization deals with will be very low in comparison.

So let's look at a very simple example, a basic course registration system.  Here are the entity types we'll deal with:

  1. Student
  2. Course

Here are some business rules around the data:

  • A student can register for up to eight courses.
  • A course can have up to one hundred students.
  • Students can see who else has registered for a course

From this simple example, I conclude that we have at least the following potential processes:

  1. Registering for a course
  2. Seeing details like who is teaching a course, costs of courses
  3. Listing who is also registered for a specific course
  4. Updating or deleting a course registration
  5. Finding out if I am allowed to delete a course registration
  6. Finding out the rules and timelines around course registration
  7. Withdrawing from a course after I have already started attending it
  8. Listing all courses I as a student am registered for
  9. Displaying detailed information about a course I am registered for, or courses for which I am not registered
  10. Plotting course schedules on a calendar so I can generate an agenda for myself
  11. Show ratings for each course
  12. Show ratings for each instructor
  13. Show the marks I have achieved for each course by term and final
  14. Show a history of my marks in the timeframe I select
  15. Show a graph of how my performance has changed over time
  16. Show a graph of how instructor performance has changed over time for selected courses or for all courses he/she teaches
  17. Update course information - new courses, remove or archive courses, update who is teaching a course
  18. Update student information - new students, remove or archive student information, update student demographic, biographical information and other information 

.... and so on ... and so on... and so on...

All of the processes I listed come directly from the two entities, student and course, along with the attributes each has and the relationships they have, one with the other.  I am sure with a little extra thought, the list could be doubled.  I am also sure that some of the processes listed have nothing to do with a student registration system, and more to do with other systems, and so could serve to put some rope around both the data (and its attributes) and the processes to be able to plan multiple projects as part of a program.

Furthermore, since we all know there is a many-to-many relationship between Courses and Students, we are probably missing an Entity Type - one that is fairly obvious anyway - something called "Course Registrations" which becomes a one-to-many relationship with each "Kernel" entity type, resolving the many-to-many relationship by adding the "Associative" entity type.  And we won't even get into the difference between registrations and transcripts, whether things like marks even belong in this model, etc.

I obviously invented  a lot of the processes I listed, and they would likely be very different if I actually had stakeholders to help me along (or would they?).  It may reveal new business rules, such as those student registration privacy or restrictions on instructor performance data, or the absence of processes, such as being able to label other students who are your friends, and seeing which courses they have registered for. 

A very simple example, of course, but from two entities (which eventually became three), I was able to derive at least 18 processes (some actually have multiple processes per line), and I did that as quickly as I could type.  Confirmation with the stakeholder would take much longer, of course.

Trying to create a long list of processes and then deriving the data from them, rather than letting the data drive the derivation of processes, is, I feel, much more complex, time consuming and subject to errors and omissions.

What do you think?  Are you process driven, or data driven?  Were you one and became another at some point in time? 

Before you answer, remember the CRUD (or CUDDL) I mentioned in a previous post.  Don't know what that is?  Look up "Of CRUDs and CUDDLs"  :)


Posted on: November 04, 2015 11:49 AM | Permalink | Comments (10)

When do requirements need to be completed?

People often ponder whether requirements for an IT project should already be in place before a project begins, whether they should be detailed at the front end of a project, or whether they should be refined as the project progresses.  The answer is not simple, and has a lot to do with the sort of project you are running.

We would all likely agree that no project can even be chartered without some level of requirements being in place - high level business requirements at the very least.  But it is a rare project that will kick off to the resounding thump of a multi-hundred page business requirements document. Most waterfall-type projects have the creation of the BRD as an early step in the project. Most Agile projects will have high level requirements, often in the form of user stories.  And then there is everything in between.

But there's the rub.  What apporach and methods are being used on your project?  Is it waterfall?  Is it one of the Agile approaches?  Can requirements change while the project is in motion?  Might such changes alter the direction of the project?

I would hypothesize that requirements can and do change on any project, regardless of the project methods being used.  Remember the old requiremernts freeze?  "You must sign here, and we will build what you have asked for.  No changes wiil be permitted from now until project end."  Seems almost hilarious now, doesn't it?  The only freeze that would really be in effect is the one that freezes you out of any more work with that client.

So - still we are left with question, "When do requirements need to be completed?". The question itself might be a tad banal. Before we design, before we build, before we test... requirements must be clear.  Do we need a 50 pound signed off document early on?  Maybe... if we are designing and building software to run a space shuttle.  But do we need it if we are only configuring an ERP package?  Or designing a web site?  Or might we need only story elaboration a bit at a time when we have a fully engaged and knowledgeable Product Owner?

As with most questions in this field the "It depends." answer pops to mind.  It depends on so many factors, including contract types, that the answer will shift like the sand dunes on the Sahara.  

It's getting cold in here. Must be those frozen requirements. 

Posted on: May 22, 2015 11:42 AM | Permalink | Comments (9)

"Talk low, talk slow, and don't say too much."

- John Wayne