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!

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

Ever been on a project where your client has already chosen a package solution?  How many times has it been based on a solid set of business requirements, complete with all those great models you can read about in PMI’s Business Analysis for Practitioners: A Practice Guide?  

In my experience, and I won’t mention any names or locations to protect the innocent and avoid shining a light on the guilty, business requirements for packages can be very sketchy, often based on a document listing many unsorted and uncategorized sentences meant to represent requirements.  In the worst cases business requirements can even be overlooked entirely.  

Why do you suppose people feel that because it is a package, it will have all the necessary functionality for a business, and that if it does not, the business can adapt?  Or that the package can be modified to meet requirements at little cost?  

Familiar with the famous term “fit gap”?  This is where requirements, however they are documented, are compared to package functionality, and the package with the highest score wins. Sadly, such analysis is often performed at far too high a level.  And worse still, the number of requirements that cannot be met are often presented as the inverse of “percent fit”.  

Sadly, the cost of changing a packaged solution to meet the 10% of requirements it doesn’t meet can often be greater than the cost of developing something to meet all requirements from scratch.  Or, the 10% some other package didn’t meet could possibly be met at a much lower cost, or even eliminated altogether if they were a low priority.

It’s a bit of a conundrum, isn’t it?  Do you spend time and money defining your business requirements in advance of making a build or buy decision when you know quite well that you are going buy a package regardless of what requirements are discovered? Are you just going through the motions? Or maybe you think your organization can adapt to the business model upon which a package was built, thinking that the package represents best practices in the associated business.

I believe no matter the route you are choosing, eliciting business requirements from the beginning and defining and managing the detailed requirements will bode well for any organization so that they can measure the success of whatever decision they make to achieve their business goals. After all, if you don’t ask the questions, you will never know the answers!

What has been your experience with the installation of packages that have been installed to satisfy specific needs? What about ERPs? Have your clients/users been satisfied with the result? Were requirements sufficiently defined prior to package purchase and installation so that a baseline comparison could even be done?


Posted on: July 07, 2016 03:00 PM | Permalink | Comments (2)

How do you run your virtual meetings?

Meetings, bloody meetings! We all remember the video John Cleese created many years back (well, some of us do, anyway), and the recent video "“Conference Call in Real Life” that is great for some big yuks. But how do you run effective virtual meetings?  

I felt prompted to write this article when I saw the many comments after a colleague posted a link to the “Conference Call in Real Life”. I thought this demonstrated that there may be a need to provide a few guidelines on how to conduct virtual meetings effectively.  Professional behavior in virtual (and, of course, in-person) meetings is the key to success.

Collecting requirements virtually is becoming more and more common as organizations try to keep costs low.  So it is more important than ever to use virtual meeting tools effectively. But it isn't all about tools.  As is so often the case, it is more about the people who use the tools.  After all, a wise man once said that a fool with a tool is still a fool.  

So, let’s get on with it, shall we?

Tips for Meeting Chairs

So, you need to have a virtual meeting.  Well, guess what?  Just a like an in-person meeting, you need an agenda.  Send it out ahead of time and ask that people prepare. Be clear about the meeting purpose and objectives. If it is a recurring meeting, allow people to make agenda suggestions in advance in case there are burning issues they feel need addressing that you didn’t think or know to include. 

When you communicate the agenda, lay out the ground rules for the upcoming meeting.  You can probably derive some ground rules from the following tips designed to help you engineer a successful meeting:

  • Tell attendees you’ll be sticking to the agenda and that “other business” can be addressed at the end of the meeting if there is time, otherwise the item needs to be added ahead of time to a future meeting.
  • Everyone is expected to “arrive” on time. In the meeting announcement, include immediate methods for testing the desktop sharing/presentation software that will be used so technical glitches can be identified and solved in advance.
  • Provide a phone number for road warriors or those who will not be connected. Ideally, though, everyone will join via computer so they can see shared screens.
  • Display action items on a shared screen. If they are not accurate, attendees are expected to speak up.
  • Input is expected, but one person will not be allowed to “hog” the floor.
  • For small meetings, ask people to locate to a quiet area and keep their mics on so everyone can hear what is going on. If someone is interrupted, stop the meeting until they are free again, just like in an in-person meeting when the board room door opens and someone interrupts.
  • Insist that attendees use headsets with microphones. Those built into computers are not good enough – they will make you sound like a robot, or like you are in a cave, extraneous noises will be picked up and echoes may result. 
  • Use a solid internet connection. If your wireless connection is flaky, use a wired connection. 
  • If material is being presented for review during the meeting, ask that it be sent around in plenty of time before the meeting so it can be reviewed, especially if feedback is being sought.
  • Create a collaboration site for storing meeting minutes, or if it is a project meeting use the project repository. I use SharePoint for this.
  • If a formal presentation is to be delivered, ask everyone to go on mute until it is time to ask questions or make comments. This is not a time to multi-task, though. It is only to make sure the speaker can be heard.
  • Record presentations and post them to the collaboration site. Make sure you let everyone know it is being recorded, and remember to click the record button before introduction of the speaker.
  • Start the meeting five-ten minutes early to ensure there are no technical glitches.
  • Check meeting tracking beforehand so you will know who to expect.
  • Send a communication five minutes in advance to all invitees to announce that the meeting will begin in five minutes.
  • Don’t start the meeting until everyone is there, or you have allowed sufficient time for laggards (I use five minutes as a guideline). Assess whether to cancel the meeting if key people are absent or not enough people show up.
  • Let people know how to use the chat window, and whether you will accept private chats.  If questions and comments may be typed in their entirety in the chat window for addressing at the end of the meeting, say so.  This is an effective way in very large meetings to handle Q&A without interruption while allowing attendees to ask questions or make comments while content is fresh in their minds.
  • Consider the use of cameras. They are not usually necessary for meetings where everyone knows one another.  But if there are new people, and they are comfortable with it, you can use cameras for a round-table introduction.  If they are not comfortable with it, consider using still pictures.

As mentioned above, you need to share decisions made and action items to which attendees commit during the meeting with the group. I find most virtual whiteboard tools are cumbersome, so I usually share a document using a word processor like Word or Google Docs. 

If you are an ambidextrous cranial sort who can take notes while thinking, chairing and talking, you can do this yourself.  Otherwise, ask a colleague in advance to take on that responsibility. But watch what is being typed, because it has to be accurate and reflective of what everyone agreed. 

Make note only of important items and action items that have been agreed, including who is responsible and when the item is due.  You can send these notes to meeting participants directly after the meeting.  No more creating minutes after the fact and having people disagree with what was written since they will already have seen what was recorded during the meeting.

Highly visible decision logs and active action item lists on your collaboration site are priceless.

Noise can render a virtual meeting ineffective.  Be sure extraneous noise is addressed politely and firmly. If you have to, force mute.  Occasionally, people are interrupted and don’t control the situation well, talking with the intruder and failing to go on mute. You can mute them and decide to continue the meeting or not.  You may need to use alternate means like their cell phone to communicate with them so they know they have committed a virtual meeting sin. This is the same as if someone gets up from an in-person meeting and leaves the room.  Should you continue the meeting?  Your call… maybe ask the person or the attendees as appropriate.

Having trouble getting some people to contribute? Try doing a round table about a specific issue, suggesting that each person talk for no more than a minute or two and that if they have nothing to say, just “pass”.  Some people are too shy to interject, but are happy if they have time to think about what they want say and know they will receive the “talking stick” eventually.  Start with someone you know won’t mind talking to give the more introverted a chance to collect their thoughts.

Tips for meeting participants:

  • Review all materials sent in advance of the meeting and make notes so you will cover the points you feel are important.
  • Behave as if you were in an in-person meeting. Avoid distractions.    Respond.  Participate.
  • If you have something to say, and you can’t get a word in, use the meeting chat function as instructed by the chairperson or use the “raise hand” function if there is one and the chairperson has said it is in play. 
  • Don’t hog the floor. If the chairperson indicates you are taking too much time, respect the interjection and allow others to speak. Be concise, brief, to the point.
  • Don’t make noise. Be aware of where your microphone is in relation to your mouth.  Heavy breathing is never appreciated.  If you hear it and it is not you, and the chairperson is not reacting, politely, perhaps with a little humour, announce that it appears someone is chewing on their microphone, or an obscene caller seems to have joined the call.
  • Be humorous. It’s alright to have fun at virtual meetings, as long as meeting objectives are met and time is not wasted. This doesn’t mean you should tell jokes.
  • Don’t interrupt speakers. It is up to the chairperson to manage people who are speaking too long. If you feel the meeting is not being managed well, consider private messaging the chairperson.
  • If you see anything inaccurate being shown in the shared action list, speak up, particularly if it is your action.
  • Be respectful. Take notes. Ask questions. Make comments. In a few words – be fully engaged, be present.

There is a certain degree of flexibility with virtual meetings that can save time and money, and you can take advantage of easy to use features (like record and share screen) that are sometimes more difficult to do in an in-person meeting. 

Virtual meetings don’t need to be like the Virtual Meeting in Real Life video, as humorous as it is since it is so very close to the reality of those in first-time virtual meetings. Let common sense, respect and preparedness rule the meeting, and success will be yours – and your team’s. 


Posted on: May 02, 2016 09:56 AM | Permalink | Comments (9)

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)

Of CRUDs and CUDDLs...

Back early on in my career as I moved from a programming role to an analyst role, I was fortunate to be funded for training by the utility company I worked for at the time.  The training was conducted by Tom deMarco of Ed Yourdon and Associates, and had to do with analytical techniques, dubbed structured analysis - mainly data flow diagramming (DFDs), and data structure diagrams (DSDs). DSDs fell by the wayside, but DFDs served me well over the years.  The basic premise was to model a clien'ts environment using sources, data flows, processes, data stores and sinks. These fanciful terms could be used in diagrammatic form to describe the "current physical" and "current logical" environments and then the "future logical" and "future physical" environements.

There were many rules and methods one could employ, such as "structured english" to describe processes, and ensuring that a process transformed the input data flow into the output data flow.  We learned that if the output data flow was the same as the input data flow, well then, there was no process at all, was there? And if there was something in the output data flow that was not input to the process, there was something awry with the process. Data flows represented data in motion and data stores represented data at rest. With all that flowing going on wasn't it thoughtful of Ed and Tom to give data a break now and then?

At the time, I was a young buck looking for the silver analysis bullet to help advance by career by doing a stellar job, and I thought this was the ultimate way to model current state and describe future requirements.  It worked very well over the years, and still does, for that matter, although I have to admit I may have become somewhat less rigid about applying Ed and Tom's rules.  

After a few years with the utility company, I moved half way across the country to join an oil and gas company. I learned about data analysis from a company called LBMS, which if memory serves, stood for Learmonth Burchett Management Systems, a company from London, England.  What they were doing in Houston is anyone's guess.  

Like the process modeling I learned about from Ed and Tom, in data there were both logical and physical aspects.  I came to the conclusion that data at rest was actually far more important than data in motion, and became somewhat of a data zealot, tossing aside my previous process modelling soapbox for a new data modelling podium, waxing eloquently (well, maybe just waxing) about logical data models, entities, attributes, relationships and obscure things like fourth normal form.  A slightly older buck at that time, I moved into the realm of data management, database administration and data-driven applications development, even helping to develop a tool that would generate code from a data dictionary based on data entity types and their attributes.  We called it the prototype system, and it was truly impressive (if I may say so myself), generating a menu structure with "CRUDs" for each entity type (Create, Read, Update, Delete).  We didn't get as far as generating reporting modules for each relationship between entities in the data model, but we could have.  A colleague I worked with subsequently insisted on calling these generated modules CUDDLs, not only because we added list functionality (hence the L) allowing the display all instances of the Entity, sorted in multiple ways as desired by the user, but also because CUDDL sounds a lot nicer than CRUD.  I have to agree. Go ahead - pronounce both and decide for yourself.  

I have seen and used many more modelling techniques over the years including use cases, user stories, affinity diagrams, and so on. I am glad to see a mix of both the old and new techniques in current materials, such as PMI's newly minted Business Analysis for Practitioners: A Practice Guide, which you can still download for free at  

So what is the message?  A guess there are a few.  Realize that many modelling techniques are necessary to do a good job in your analysis role - so learn many of them. If you must be a zealot about something, choose modelling. Don't choose a specific hill upon which to die. It's not a war, and there are many hills worth saving.  

Now, does anyone know what you call a ... shall we say ... seasoned buck?

Posted on: March 20, 2015 03:47 PM | Permalink | Comments (3)

"I'm not afraid to die, I just don't want to be there when it happens."

- Woody Allen