I first became interested in agile when I was leading technology teams and consistently struggled with the standard waterfall challenge of getting accurate, complete, well understand and well documented business requirements for long software development application projects.  Once we felt like we finally got things “nailed down” and began design and development work, requirements would change before we could deliver the first release.  The agile methodology is a natural solution for this.  I began my own course of self study, networking and training, and eventually acquired a scrum master certification.

To understand the principles of any of the flavors of agile methodology (and there are several), you need to first understand the agile manifesto, developed by the original set of agile founders:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Scrum happens to be one of the most popular types of agile and derives its name from a daily standup meeting called the scrum meeting, involving the team and the facilitator who is called the scrum master.  Below is a discussion which breaks down some of the important roles used in scrum and compares them to their analogous counterpart in a waterfall methodology. 

Roles – there are only 3 officially recognized roles on an agile scrum team:

• Product Owner – The product owner is a member of the scrum team and is responsible for what the team builds and for optimizing the value of it.  He/she owns decisions and risks regarding what business stakeholders want.  He/she defines the features to be produced and decides on release date and content, and determines feature priorities.  He/she can change features and priority between sprints.  He/she negotiates acceptance criteria for work results with rest of team
• Scrum Master – facilitates process and keeps things moving.  He/she manages the internal dynamics of the team including the relationship of the product owner with the rest of the team.  He/she enforces the scrum framework.  He/she ensures full team involvement in all meetings and keeps everything visible, including “radiating” information to the larger organization.  He/she shields the team from external interference.  He/she advocates improved practices.  Very important:  He/she facilitates, but does not manage.  The scrum master has no official authority over the team.  He/she cannot assign work to the team.
• Team – This is a small (7 +-2 member) cross functional group who are responsible for the work they agree to take on during the work period called a sprint.  They are a self organizing unit – meaning they assign sprint work tasks to themselves.  They negotiate the work of the sprint with the product owner.  Along with the product owner, they demo the work results to the stakeholders.

The product owner is analogous to a business analyst, product manager or sponsor in a waterfall methodology, and the team is similar to any team anywhere, with the exception of the self organizing part.  That’s a little loose-y goose-y for a lot of management teams to get used to.  Frankly, what I’ve seen in a lot of companies I’ve networked with is a gradual approach to this, because as much as this sounds like a great goal, in companies that have been highly command and control, teams have to get as used to it as the managers themselves do.  The scrum master could be similar to a technical team lead or a technical project manager in some organizations.  What is strikingly missing in this model is the overall project manager him/herself.  The traditional, all controlling, project manager doesn’t really have a direct correlation.  To find a home in an agile practicing organization the PMI style project manager has to make some decisions.  For individuals with a more product oriented, business slant, the product owner might be a great role to assume.  For the more technically minded, the scrum master role might be a better fit.

One of the most intriguing differences between agile and waterfall and what in my mind makes agile so compelling is in the area of scope control.  In the waterfall methodology we go to great lengths to define the scope of the project in as much detail as we can all up front, and then protect that scope.  We define a rigid scope change process which acts as a deterrent to anyone who wants to introduce changes to the work that we already have a complex tangle of design plans around, because of the cost and pain of implementation when you work on everything all at once.  With agile the notion of scope control is virtually non-existent, except within the context of the short periods of work, called sprints.  This is by design.  This is to allow and even encourage the product owner to be flexible and change their mind in between sprints as the business sees the results of work and reacts to it; and as events in the business change. 

In a nutshell, product features and all other work are maintained in a document called the product backlog, in single threaded priority by the product owner.  The team determines “chunks” of that work off the top that they can perform in time boxed periods of work called sprints (usually 30 days).  Once a sprint starts, the scrum master insures that the scope of the sprint does not change.  At the end of the sprint the team and the product owner jointly demo the work that has been completed to the business stakeholders.  The product backlog is reprioritized if necessary by the product owner and another sprint is started.  Sprints are repeated until enough work is completed to comprise a release.  Sounds simple huh?  Well there’s a little more to it than that.

In my next article I will discuss the small set of artifacts, meetings and processes involved and discuss what they compare to in a waterfall context.

And while conventional wisdom says that social media is used primarily by the young, that’s not really true.  According to Forrester Research, the percentage of Boomers consuming social media was 67% for younger Boomers (ages 43 to 52) and 62% for older Boomers (ages 53 to 63) in 2008.

In its Boomers and Social Media report, eMarketer notes that Boomers love Facebook far more than other social media sites, with 73% of the group claiming to maintain a Facebook profile. 

So, how can a project manager use social media?  Below are some ideas, but first a word of caution: when incorporating social media into your PR campaign, pay special attention to security and privacy issues.  The appeal of social media is its wide accessibility and its easy access, two strengths that can backfire on you, or someone on your team, if you share something your organization isn’t comfortable with.

Medium: Blogs / Wikis

Idea: start a project blog

A blog or wiki site is a great way to share project information and gather feedback, which helpts to create a collaborative environment.

YouTube

Idea: post a PowerPoint with music or audio or a simple video

This is a fun way to control your message and build your team.  Video messages from project leadership or sponsors can mean a lot to a dispersed team.  Video messages from different work sites can speed the process of building a virtual team. 

Twitter

Idea: create a group on Twitter using a unique hashtag

Twitter is best used for team building.  Create a hash tag for your project, a unique name preceded by the # sign, and make sure all of your Tweets include it.  Then your users can search for all the Tweets about the project.  This can be particularly engaging for a dispersed team, is popular with cell phone users, and can be used for quick updates in “teamspeak”.  Twitter feels much like instant messaging, but conversations on Twitter are searchable, so they are not private.   

Facebook / MySpace

Idea: create a project page in Facebook

A project page on Facebook or MySpace allows shareholders to comment and provide feedback.  This can be an engaging way to build a diverse team.  You can share project information or just fun stuff like pictures and videos of social gatherings or meetings.   These sites do have some privacy settings that will help you control who views this content. 

Linked In / PM Net

Idea: Research a project challenge on a business networking site

This is a great way to connect with experts in your field, gather a lot of ideas in a short time, and find or start a discussion about a topic that interests you.    

SharePoint/Google Sites:

Idea: Leverage the best ideas from social media for your internal tools

If you can’t take advantage of external social media tools, take the collaborative features that make social media so popular and apply them to your internal tools.  Start a blog, use videos and pictures, have a contest, just get people interested in collaborating.

• Interviews – a one on one or one on several (2-3) of stakeholders question and answer session guided by a pre scripted list of tailored questions.  The questions should be comprised of a set of context free inquiries to promote bias free discussion.  Once the context free answers have been documented, some solution specific questions can be used to explore stakeholder leanings related to specific solutions.
• Brainstorming workshops – a facilitated multi hour, perhaps all day session with all key stakeholders present.  There are usually ice breaking and warm up exercises to set ground rules and promote free thinking.  Then there is grounding in basic project material, followed by group brainstorming to elicit multiple ideas.  Usual rules are to generate as many ideas as possible, piggy back ideas off each other, and suspend judgment on any idea. Towards the end of the workshop the ideas must be grouped, clarified, reduced and prioritized.  These sessions are notorious for sometimes being difficult to manage and requiring the skills of a trained facilitator – preferable one from outside the organization with no political ties to any of the stakeholders.  Typical challenges include:
  • Time Management
  • Domineering
  • Lackluster participation
  • Negative, petty comments
  • Turf wars
  • Post lunch energy sag
• Role Playing – basically this is like walking a mile in the stakeholder’s shoes.  When possible the analyst carries out a day in the job of the stakeholder he/she is trying to gather requirements from – i.e. using the computer application to enter an order, welding a part, etc.
• Scripted walkthroughs – similar to role playing, when an actual role play is not possible, this method allows a simulated experience via a script.
• Prototypes – typically used in the context of a software development effort, a prototype is a partial implementation – a mock up of the external interface or what the stakeholder experiences when he interacts with the system.  This is a good way to let the stakeholder play with the model and discover what feels to be missing.  This sometimes uncovers entire feature sets that until then were unexpressed.
• Storyboarding – Similar, but less elegant than prototypes, story boarding is used to gain early reactions from stakeholders on concepts proposed for deliverables.  Story boards can exist in 3 different styles:
  • Passive, containing screen shots, written business rules, process flow diagrams, output reports, etc. all laid out in a sequence so as to paint a picture or tell a “story” about how things will work.
  • Active, containing slideshows, animation, or simulations to try to make stakeholders see a movie that hasn’t been created yet.
  • Interactive, requiring participation in order to allow the stakeholder to experience the system in as realistic a manner as possible.

From my experience, I like to employ a combination of the above methods.  Personally, I never like to convene a large group to discuss anything with a blank sheet of paper.  I believe beginning a large group session with no content already established at least at a high level – i.e. a blank canvass is an invitation for chaos.  My preference is to outline the areas of requirements and determine who the primary stakeholders are for each area first, from analysis of project objectives and discussion with sponsors.  Then create a targeted questionnaire around each focused area and interview 1 – 3 primary stakeholders who are most directly affected / involved with the topic to get the core facts.  Sometimes a role play or scripted walk through can be combined with an interview to allow the stakeholder to demonstrate their world to the business analyst.  The larger “big tent” sessions can then be a refinement or validation session of those core facts by secondary stakeholders who can add their concerns and needs.  These secondary stakeholders may be primary stakeholders of another area. 

Once an initial set of requirements have been gathered story boards and prototypes allow analysts and implementation teams to demonstrate back to the stakeholders whether they “got it” right and seek verification before they commit to final implementation.

Requirements elicitation is hard work requiring a mind meld of those participating in the process on whatever level of detail is being discussed. The more you limit the number to those who have expertise on a focused topic, the more likely you are to reach consensus.

What are your thoughts?

References:

Leffingwell,D., Widrig, D. (2000) Managing Software Requirements, A Unified Approach, Upper Saddle River, NJ: Addison-Wesley.

Use Cases – are used to describe scenarios of operation of a system.  Typically unique roles or “actors” are defined, and the use case or actions carried out by those actors as they interact in the variant ways with the system.  As each unique variant is described a process diagram in words is built.  According to Wikipedia, there can be 3 conventional levels of detail for use cases: brief, casual, or fully dressed.  In the fully dressed version use cases contain:

• a name, number and a version section for identification,
• goal and summary sections to help clarify the purpose of the use case,
• actor and stakeholder sections to identify the performing role and affected agent role,
• preconditions and trigger sections to describe conditions that must exist and event that initiates respectively,
• basic course of events section that describes the primary and normal scenario,
• alternative path section that describes exception scenarios,
• post condition section that describes the change of status after the use case completes, and a
• business rule section that documents policies related to the use case,
• general notes section,
• author and date section

User stories – are used with Agile methodologies.  They are written by the product owner or customer, and they are usually limited to a few sentences that can easily fit onto a 3 by 5 index card.  They are intentionally meant to be brief to keep them from becoming too structured or formal and to promote, well agility.  The idea during design is to encourage conversation between developer and customer, more than extensive documentation.  The specifications will be assured through an accompanying acceptance test.  User stories usually have the form of:

As a [Role] I would like to [do action] because [reason]. 

As the details get filled in through dialog, the acceptance test gets defined and verification occurs in the agile methodology at the end of the iteration in the customer demonstration, using the acceptance test.

Other generic formats – whether downloading templates for free from collaborative shareware sites or purchasing moderately priced forms or templates, or developing your own home grown version, there are many structures and styles governed by no particular standard.  Most will have some or all of the following sections (shown here in the context of a software system development project ):

• Project /Problem Description section discussing basic needs and business drivers
• Goals / objectives section
• Project Approach / Scope
• Assumptions and Constraints
• Risks and Dependencies
• Deliverables and high level milestones or target delivery dates
• High level budget
• Stakeholders / Roles
• Processes – current state and to-be state
• High level Requirements
• System interfaces
• Product requirements
• Organizational requirements
• External requirements
• Usability requirements
• Performance requirements
• Operational maintenance requirements
• Reporting requirements
• Training / Documentation requirements
• Infrastructure requirements

What most of these approaches have in common is that they allow multiple layers of granularity from high level to lower levels of detail and specificity.  This supports a progressive evolution into “clusters” of business specification information.

Putting it all together, the example below illustrates how we can maintain traceability between goals, objectives, and requirements, and detailed specifications of our requirements.  Mining a requirement template with categories, you can remember which categories to think about when developing requirements and specifications for any project. 

In the following example involving installation of a home security mailbox, two high level goals and a more specific, measurable, related objective are listed.  Then using a generic document format modeled after a requirement template we capture specifications for the mailbox itself.  In this environment we might have a homebuilders’ requirement template that has general requirement sections around such things as foundation, framing, electrical wiring, plumbing, interiors, landscaping, security, convenience features, homeowners specifications, city/government regulatory requirements, etc. 

Example:

Goal #1 :  I wish to be free from the perils of information theft

Goal #2:  I want to stay out of trouble with the homeowner’s association

Objective #1 (related to Goals 1 and 2): I wish to safeguard the mail delivered by the US Postal service to my house in a way that prevents theft, for a cost no more than $500.00, by the end of the year that complies with the homeowners’ code.

Requirement Specifications using generic template format:

Requirement #1 (related to Objective #1):  Install a security Mailbox

1.1    Homeowners’ specifications

1.1.1          Base must be made of brown brick

1.1.2          Height must be between 3 and 4 feet

1.1.3          Width must be 2 feet

1.1.4          Depth must be 2 feet

1.1.5          Top must be angled 125 degrees

1.2   Security specifications

1.2.1          Mail in lever closes locking mail from manual retrieval

1.2.2          Retrieval from bottom with key

1.3   Convenience specifications

1.3.1          Two retrieval keys

1.4   Governmental Regulations (US Postal service)

1.4.1          Address plate on front

1.4.2          Must be installed no more than 18 inches from curb

Next, we will define the normal retrieval process using a use case format.

Use Case: SecureMailRetrieval 1.0 v1

• Goal: Retrieve postal letters from a secure mail box
• Summary:  The owner uses his key to retrieve letters securely from mailbox.
• Actor:    Homeowner
• Stakeholders:  Postman, Thieves
• Preconditions:  Mailperson has delivered mail.  Homeowner has key
• Trigger:  Mailperson has delivered mail.
• Normal Scenario:  Homeowner uses key to unlock bottom compartment.  Retrieve mail.  Lock back
• Alternative Path: Mailbox is empty.  Lock back.
• Post condition:  Mailbox is empty, mailbox is locked.

Finally we will define the Mail delivery process as an Agile user story and acceptance test

User Story: SecureMailDelivery

• As a Mail carrier, I would like to be able to deliver mail to mailboxes with security compartments without needing a key because I will not have access to homeowner mailbox keys.
  • Acceptance test: Mail carrier has access to input compartment without key.  Once mail is inserted and door is closed, letters cannot be retrieved without key.

 Regardless of what form you use, requirements should be developed with progressively more detail and linked back to the high level requirements, objectives and goals that they originate from.  This helps us organize and make sense out of the forest and trees and leaves of a project’s requirements and related specifications and business processes.

In this case, the project manager is retired U.S. Coast Guard Adm. Thad Allen, who is in charge of the federal government’s response to the oil spill resulting from the April 20^th explosion at one of British Petroleum’s (BP) offshore oil rigs in the Gulf of Mexico.  His title is officially National Incident Commander, but that just means he’s the most senior project manager on this mess.  I simply can’t imagine all the constraints he is juggling as he attempts to right things in the aftermath of the largest offshore oil spill in the history of the United States. 

Just consider force majeure effects the project manager has to deal with, particularly the weather.  Today, Day 96, brings the news that the cleanup effort that was halted due to the expected arrival of Tropical Storm Bonnie, is back on, as Bonnie failed to materialize.  Before anyone breathes a sigh of relief, however, officials are quick to point out that this is the season for tropical storms.  Weather experts are predicting ten this year and Bonnie was only the second.    

In Cindy’s blog last week, she talked about managing the public relations around troubled projects.  In the Deepwater Horizon situation, oil rig owner BP can hardly have done a worse job in the PR department.  CEO Tony Hayward has come across as flippant and out of touch in his many appearances before an American public that is very concerned about the environmental and economic impacts of this catastrophe.  In a dubious attempt to improve the company’s image, BP Board Chairman Carl-Henric Svanberg stated several times that “We care about the small people,” which didn’t necessarily warm the hearts of the stakeholders who had not, until this point, considered themselves “the small people”.  Fortunately, Allen has done a much better job with project PR than his “client”, BP, by appearing to be a straight shooter: providing frequent updates with as much clarity as the situation allows.  

With the passage of time and lawsuits and congressional hearings, we will learn much more about all the things that went wrong with the Deepwater Horizon rig and how they contributed to this disaster, resulting in the need for a “response project”.  And certainly the response itself will be studied by scholars of all types of disciplines, who will attempt to capture lessons learned from this highly visible, and downright painful, public mess.

But as project managers who may at some point in our careers be called on to lead an almost impossibly troubled project, what lessons can we learn as we watch the situation unfold, from a safe distance and with an increasing benefit of hindsight as each day passes?  And what can we identify that is going right, so we can repeat them on our own troubled projects?

I am eager to hear your observations.  At this point in the response project, I can identify two areas for the “What Went Right” column:

1. Admiral Allen as the leader of the response project definitely goes in the “What Went Right” column.  Not only does he have almost 40 years of service in the Coast Guard, a Master of Public Administration degree from George Washington University and a Master’s degree in Management from the MIT Sloan School of Management, he was also lead Hurricane Katrina onsite relief efforts in September 2005, and his stewardship of that project was highly regarded.  People in the Gulf know him and respect him.  He has a track record and the perception is that if anyone can get their arms around this mess, it’s him.
2. Another check in the “What Went Right” column goes to adequate resources.  So far, BP has seemed quite willing to foot the bill for the cleanup effort, although many of the business affected need more relief faster.  With time, we will understand exactly who is at fault for what, and BPs willingness to accept responsibility may turn out to be a shrewd PR ploy instead of a demonstration of corporate responsibility.  Nonetheless, right now it’s nice to see resources being committed instead bickering about who will pay for it.  There will be plenty of time for that later…

Please let me know what your thoughts are about the response project, and if you can identify anything else that is going right.

In many respects, the successful planning and management of a turn around project are similar to a normal project.  It requires a new charter, and project plan to evaluate the failings of the first project and define the actions required to correct course.  There are many dimensions to a troubled project, and many things that must be done.  This will not be an article to attempt to discuss all the aspects of how to address a failed or troubled project, but how to address the communications and more specifically – the public relations during the turn around effort.  Through the course of this blog I have written many articles about public relations on projects.  The communications and public relations campaign of a turn around project certainly require the same PR principles that any project does such as:

• Communications message content focused on benefits, helping to keep stakeholders’ focus on the ultimate goal to be achieved at the end of the journey.
• Messages relating not just the information of activities or events, but conveying the value of those events to the business.
• Communicating information promptly, when it is of prime interest and relevance to stakeholders.
• Being aware of the spin or nuance in a message and selecting the appropriate tone of a message that is right for the target audience.

What is different about a troubled project, however, is that unlike a normal project, the project manager does not start with a clean slate and friendly stakeholders.  On a normal project everyone gives you the benefit of the doubt at the beginning.  The project manager can leverage the natural excitement that exists around a new undertaking and create friends of the project.  Once things begin to go awry, all that is lost and stakeholders are now mad.  The recovery PM operates from a position of a PR deficit.  As the public “face” of the project, he/she may no longer have any credibility and this requires extra finesse in the public relations campaign. 

There is no fast or easy way out of the PR deficit position, other than real performance – i.e. actually beginning to make some of the new commitments.  Until that is possible, a certain amount of humility when wearing the “project face” is just part of the role.  What stakeholders tend to want at this point is honest, clear, reliable, complete, straightforward, and prompt information.  As you and your team are performing discovery and identifying priorities, it is important to publicly acknowledge them – even before you may know the solutions.  This helps ease stakeholders’ anxieties that they have been heard and understood.  Your ability to quickly establish the stakeholders’ belief that the information being communicated is reliable and objective establishes credibility. It needs to be complete to insure that quality decisions are derived as a result.   Stakeholders want an open admission of mistakes that were made.  Fortunately, project management gives us a good framework that allows us to discuss such things as lessons learned in a respectful way that retains dignity for the team – especially when combined with process improvements that were implemented as a result of those lessons.  This is important to preserve the morale of the team because the team must carry out the required recovery work. 

A recovery project will probably institute more frequent feedback loops and communications should follow suit.  You cannot afford to let the silence created by a void of information generate panic driven false rumors.  PR during a troubled project therefore becomes very time consuming and it is a good idea to consider appointing a lead who is devoted to managing PR and frequent, prompt communications while the implementation team focuses on resolving issues and carrying out the work.

But what if the stakeholders themselves are the problem?  As described in the ESI International white paper entitled “Saving Troubled Projects”, one of the first things that must be discovered is project history and sensitivities.  As with any project, having a strong supporting sponsor with the appropriate level of seniority and credibility is essential for success.  This sends a clear message to stakeholders that this work is of importance.  The recovery project manager must make an effort to understand the political environment the project has operated in.  He/she must fully understand the objectives of the project, as well as the objectives and motivations of the stakeholders and where those may have been in conflict.  The sponsor should be leveraged to handle stakeholders whose motivations may be at cross purposes with the goals and objectives stated in the charter. 

In summary, a recovery project manager must use all the public relations tools employed on normal projects to an even greater degree on a troubled project to keep stakeholders eyes on the prize as the team rights the ship back on course.

Pulling the plug on a project is an interesting change management issue. While we as project managers sign up for a project knowing that it is, by definition, temporary, we want it to end because we have finished the work, not because the organization no longer wants it.  And we get very emotionally invested in our projects, maybe because they are temporary, and we feel like we can really make an impact during our brief stewardship.  As a result, we can suffer some real feelings of loss when a project is cancelled, just like any other member of the project team.    

So I was very interested when I came across an article in CIO magazine recently, entitled When IT Projects Founder, Emotions Run High, by Michael Fitzgerald.  “It’s hard not to get emotional when lengthy, high-profile technology projects are unfairly killed, mercifully euthanized or launched with flaws.”, Fitzgerald writes. 

Fitzgerald shines a light on a slightly embarrassing topic for many IT folks.  It’s, uh, about, ahem, feelings.  It is that reticence to talk about feelings that can cause so many problems when a project ends unexpectedly. 

 “Every killed or troubled project has its own particular tale of woe”, says Fitzgerald.  “Some suffer because of unforeseen events — the end of the Cold War, an economic downturn, a merger, a shift in business priorities.  Some founder because of a bad combination of technology, ambition and skills. But whenever projects stumble or even die, and people feel wounded, it usually has something to do with that most persistent of people problems: communication.”

If you are going to spend your summer with a dying project, don’t forget to attend to the feelings that people have about their work.  Once asked to make a commitment to a project, it can be hard for many people to just to flip a switch in their mind and divorce themselves from it.  People need to talk about how they feel at the end of a project, and a good project manager will help them.

One easy exercise that can help bring closure to the project team is the Glads, Sads, and Mads Exercise.  Think of this as a Lessons Learned session for emotions!  Assemble your team, perhaps in a casual or offsite setting, and go around the room, asking each person to share three feelings about the project:  why they are glad the project is ending, why they are sad it is ending, and why they are mad it is ending.  This helps the team by getting their feelings out in the open and hearing fresh perspectives.  They may be relieved to learn that others have strong emotions, too, and may be pleased to see the level of commitment expressed by their teammates.

Whatever you do, don’t ignore the emotional side of a cancelled technology project.  Make sure your team members don’t care negative feelings or emotions on to their next project by helping them deal with their feelings when they close out the old project.

It is generally considered that a well defined requirement possesses the following attributes:

• Necessary – The system cannot meet prioritized needs or goals without the requirement
• Feasible – The requirement is doable, within available cost and schedule
• Correct – The facts related to the requirement are accurate and it is technically and legally possible
• Concise – The requirement is stated simply
• Unambiguous – The requirement can only be interpreted one way
• Complete – All applicable conditions are stated, and the requirement expresses a whole idea or statement.
• Consistent – The requirement is not in conflict with any other requirements
• Traceable – The requirement can be traced to its source, and it can be tracked throughout the system, (e.g., to the design, code, test, and documentation)
• Allocated – The requirement is assigned to a component of the designed system
• Design independent – The requirement does not impose a specific implementation solution
• Non-redundant – The requirement is not a duplicate requirement
• Stated using a standard construct – The requirement is stated as an imperative using the word shall
• Associated with a unique identifier – Each requirement has a unique identifying number
• Devoid of escape clauses – Requirements do not use if, when, but, except, unless, and although, and do not include speculative or general terms such as usually, generally, often, normally, and typically.

Additionally, a business requirement differs from a business rule.  According to Gladys S.W. Lam, Principal at BRSolutions.com, who writes in her article, “Business Rules vs. Business Requirements,” Business Rules Journal, Vol. 7, No. 5 (May 2006), URL:  http://www.BRCommunity.com/a2006/b290.html  ,

• Business rules are lists of statements that tell you whether you may or may not do something or that give you the criteria and conditions for making a decision
• Business requirements are what you need to do to enable the implementation of and compliance with business rules.

• Business rules are what they are.  They shouldn’t change to fit the business requirements.
• A change in a rule can mean different or additional requirements.

An example of a business rule might be: 

A Customer must have an Email Address

The associated business requirement that enables implementation and compliance with that business rule is:

Customer must have capability to enter email address for a customer. 

The solution chosen to implement that requirement might be to provide a GUI. 

Obviously, requirements such as the one stated above are still fairly high level and must still be broken down further before they could be actionable by an implementation team.  There are still more detailed specifications related to the capability to enter an email address such as which fields to enter, error handling, and many other aspects that a development team should define.

Business requirements are best defined in layers with a set of un-actionable requirements such as: Customer must have capability to enter email address, at one layer, and the lower level specifications related to that requirement captured at a layer beneath it and tied back to the requirement above it.

According to Dictionary.com, a template is “anything that determines or serves as a pattern; a model”.  The idea of a Requirements Template is to provide your organization with a thorough and far-reaching list of questions or areas of inquiry to either answer or rule out at the beginning of every project.  If you include input from enough people and groups, whether they typically identified as project stakeholders or not, you can eliminate many of the scope problems that your organization’s projects might have encountered in the past. 

If you ever do projects for external customers, start your template-building exercise with Marketing and Business Development.  Ask them about what types of features customer and prospects initially express interest in and what marketing and advertising messages they respond to.  This can give you some good high-level areas of inquiry for your Template by helping you understand what prompts your external customers to engage with your organization. 

Next, visit with the Sales group and ask them to think about every problem customers have identified as wanting to solve when they accept a sales proposal.  Ask them also to think about customer satisfaction issues after a sale is completed:  what characterized projects that had satisfied customers, and what characterized projects that didn’t.  Ask them to describe situations where the customer was temporarily unhappy and why.  Ask to see any type of documentation they use to begin identifying what a customer wants. Then start building your list of questions. 

If you are dealing only with internal customers, start by reviewing the documents that accompany any request for a new project.  You want to include all of this information, but your template will go into much greater detail.  Interview someone from your organization’s Steering Committee and ask them what is missing from the current initiation documents they use.  Ask for examples of specific projects that got kicked back from the Steering Committee due to insufficient information, and get them to identify the types of additional information needed for them to make a ruling on a new project.  Continue building your Template by adding this to your list of questions.

Next, visit with all the teams that are responsible for executing the project plan.  Talk to developers, DBAs, cost estimators, trainers, folks who do the documentation; basically, everyone who actually performs work on a project in your organization.  Ask them for a list of everything they end up needing to know in the middle of the project that no one ever asked at the beginning.  Ask them what kind of work they are doing in the stabilization period, and if that work is a result of missed requirements.  Ask them for the most common examples, as well as the outliers.  Your goal is to create a comprehensive list of everything that should be considered at the beginning of a project.

Then move on to your support teams – whoever is responsible for the product of the project once it is operational.  Ask them to identify the things they wish someone on the project team was asking about.  Again, ask for the odd and unusual situations as well as the most common examples.

Finally, spend a little time with other groups that may not be at all involved in the project, but can potentially be affected problems with a project, like Legal, Accounting, Corporate Compliance and Public Relations.  Ask if they have ever been affected by missed project requirements, or have an area of potential concern around project requirements.  Document their concerns as areas of inquiry to consider during the requirements phase.

If you have all these conversations and hear all these war stories, you will be able to create a useful tool for the people in your organization who have the responsibility of collecting requirements.  Continue to updated and modify your Requirements Template as new information becomes available. 

In addition to getting your project off to a good start and nipping some scope creep issues in the bud, you may find that this tool helps you have better conversations with customers, both internal and external, by helping them uncover needs they didn’t know they had or gaps in their process they hadn’t discovered yet.

Good luck!