Skip to main content

Tag: Software

Requirements Gathering in a Flat World

In his 2005 bestseller The World is Flat, New York Times columnist Thomas Friedman famously proclaimed that advances in global communications technology had essentially rendered the world flat. By this he meant that the massive investment in communications infrastructure that fueled the dot-com bust has, as a virtuous by-product, allowed a new generation of companies to leverage cheaper resources abroad.

And has it ever!

The ubiquity of persistent Internet access has enabled a new generation of companies to leverage resources – be they human or IT-based – wherever they might be physically located. Regardless of how you feel about the political implications of offshore outsourcing, it’s clearly no passing fad.

It wasn’t too long ago that developing software via offshore outsourcing belonged solely to the province of large enterprise organizations. This of course is no longer the case as even the smallest companies have come to rely on distant software development teams in Eastern Europe, former Soviet republics, and Asia. In fact, this ability to instantly tap cheaper development resources and expertise has directly contributed to a burst of innovation, as smaller companies are able to level the playing field with their larger enterprise counterparts.

Yet this opportunity also comes with some thorny strings attached – any short term savings realized can be quickly offset by poor requirements definition and gathering practices. As business analysts well know, clearly articulated software requirements represent the foundation of any successful software project. Indeed, the reason why so many software projects continue to fail is precisely because not enough attention is paid to this critical first step in the software development process.

Communicating and managing software requirements is of course challenging enough even when all your team happens to be situated in the same location. But when working with a distributed team, many of whom don’t even share a common first language, the potential for errors grows considerably. And thus, any savings realized by cheaper resources is suddenly squandered. Worse still, time is wasted, morale suffers, and the project team is forced to shift into “fix-it” mode.

On-Demand Apps Grow Up

When was founded in 1999 by former Oracle executive Marc Benioff, the notion of applications hosted “off-premise” was still something of a radical idea. At that time, there were still a number of barriers to widespread adoption: application performance, security assurances, and bandwidth constraints, to name but a few.

Just 10 years later, practically every major software category now includes a healthy ecosystem of on-demand solutions. Not only has the supporting infrastructure matured with offerings like Amazon’s EC2 cloud platform – allowing software providers to more easily configure their application in the cloud — but the next generation of on-demand applications are pushing the envelope in terms of what can be delivered through a browser. More and more, these applications feel and act like traditional desktop software. But of course, they can do so much more because they are intrinsically connected. Now, every on-demand application has the potential to become a dynamic collaboration platform that succeeds in bringing all project constituents to the table. And, as more on-demand application developers create and publish their APIs, they can be integrated into other facets of the software development process.

But it’s this idea of connectedness that’s so powerful when it comes to keeping distributed teams marching to the same beat. Business analysts are not just responsible for defining requirements but also for ensuring that they’re properly communicated and correctly applied. While large enterprises might have the luxury of a robust requirements management tool at their disposal that incorporates collaboration (and surprisingly, only a small percentage of these enterprises have adopted these types of solutions), the average small to medium enterprise does not. Instead, most of these companies use some combination of Word, Excel, and email to define and communicate requirements to their development teams. Because these tools are disconnected from one another, the potential for miscommunication is an endless challenge. And when those development resources are located half a world a way, it’s not a question of if something will go wrong but rather when.

So what’s a budget-minded business analyst working with a distributed development team to do?

Requirements Outlook? Mostly Cloudy.

In many respects, business analysts can find inspiration in the latest hype cycle: social media. Social applications like Facebook and Twitter have reshaped our personal dialogue and communications framework. And aspects of these sites will likely transform the way we think about software requirements.

For better or worse, we are in constant communication with our own personal circle of contacts. Anyone who has been part of a software development team understands how important it is to be in regular contact with the rest of the team. From the beginning of a project (i.e., defining use cases) through the implementation phase (i.e., bug tracking), persistent communication is the new Critical Chain. Put another way, when you can’t all be present for the daily stand-up meeting, how do you ensure everyone is on track?

There are three key ways that migrating the requirements gathering process to the Cloud will help business analysts get better results from their distributed development teams:

Collaborate in Real Time, in Context. Email is a terrific communications tool. But it’s asynchronous and often detached from a larger context. This becomes especially problematic when multiple teams are working on different aspects of the same project. By unifying the requirements process in a hosted environment, distributed teams can collaborate in a meaningful way and identify potential problems before they get out of hand.

Visualize the Workflow to Mitigate Language Barriers. One of the most vexing challenges that business analysts face when it comes to working with offshore developers is communicating across multiple languages. There are the obvious spoken language barriers to overcome. But more often it’s the nuance and culture of language that presents the most significant obstacle. Because business and software requirements are technical in nature, employing a visual language to communicate requirements becomes a necessary complement. As traditional requirements gathering tools move to the Cloud, the ability to clearly represent business requirements in a visual manner (i.e., use case scenarios, parking lot diagrams, etc.) will help keep all project constituents on track.

Visibility for All, Across the Entire Requirements Spectrum. No software developer should be an island to themselves. Even though two developers might be working on two discrete and unrelated tasks, it’s still vital that they understand the underlying business requirements that are driving the project. By standardizing the requirements management process in the Cloud, the business analyst can provide all of their team members with the “situational awareness” they need to understand how their software will be used.

In Flat We Trust

The world is indeed becoming flatter by the day. Just as the path of water naturally finds the path of least resistance, free markets will invariably gravitate towards the most cost-efficient resources. However, even with all of Friedman’s optimism regarding the potential rewards of offshore outsourcing, he also goes on to warn us: “In this era of mounting complexity with more people, systems and products entwined in a bewildering web of global networks, explaining is an enormously valuable skill.” In a sense, that is exactly what software requirements are all about: explaining. And explaining becomes all the more important when teams are fragmented by geography, culture, and language.

Don’t forget to leave your comments below

Darren Levy is the founder of, a provider of on-demand requirements management solutions based in Los Angeles. Email him at [email protected].

Using the Requirements Creation Process to Improve Project Estimates


Estimation can be one of the most difficult parts of a project. Important questions must be asked in order to form the right figures and plans. How long will the project take? How many resources will it consume? Consultants may also ask the following question: What is the appropriate amount to bid on this project? These questions are not easy to answer at the outset when one generally has only a vague idea of what will be required throughout the project.

The good news is that there is a fairly simple way to improve project estimation and, consequently, the bidding process. Most people do not realize that the requirements creation process can lend insight into the length and scope of a project. Let me give you an example of how this method works and then explain how you can implement it within your own company.

The Story

Back in 1992, I was working for a consulting company named The Kernel Group (TKG). During this time, I was put in charge of porting Tivoli’s software from Sun’s Solaris operating system to IBM’s AIX operating system. The project was to be done under a fixed bid, and consequently, we at TKG knew that estimating the effort required to port the code was of paramount importance.

I looked at the code with a coworker of mine, and he came to the conclusion that if Tivoli didn’t make the project hard for us in some unspecified way, we could port the million or so lines of code in about a weekend. I told him that he was nuts – that it would take at least a week, maybe even two. We jointly decided that we probably ought to call it three weeks just to be safe. We also decided, rather smugly, not to report our padding of the schedule to evil upper management.

As a result, evil upper management drastically expanded the project bid to $325,000, and my coworker and I thought that this was a ridiculously high price. We believed that we were gouging the customer and that they would never accept it.

Yet they did accept it, and once the project began, we proceeded to discover how truly terrible we as software engineers were at the task of project estimation. To make a long story short, the porting schedule expanded to exceed our original estimate and we consumed not only all of the $325,000, but a whole lot more on top of it.

The Formula

Now our consulting company was religious about tracking employee time on a per-project basis, and so we broke every project into phases: requirements/specification, design, coding, testing, debugging, documentation, training, etc. This project was no different in that respect; we broke it down into its respective phases as well.

Just before we started working on the project in question, I read a book called Practical Software Metrics for Project Management and Process Improvement by Robert B. Grady. (By the way, this is a truly fabulous book that I would highly recommend to anyone who is managing software development projects.) According to the book, one of Grady’s rules of thumb is that 6-8% of every software project is usually eaten up in the requirements/specification phase.

One of the conclusions that Grady comes to in his work is that you can use this fact to estimate total project size. In other words, if it took 60 hours to do the specification, that’s probably 6% of the job and the job will be 1000 hours. Following such logic, a six hour specification implies a 100 hour job. Since the specification always comes first in any project, you can get some pretty reliable estimates from this method alone. In fact, in my experience as both a programmer and the CEO of a software company, I have found it to be incredibly accurate and useful.

A second way to triangulate this project estimate is to ask experts in the area for their opinions – hopefully they will be better at project estimation than my coworker and I were that first time. A third way is to select an appropriate metric for estimation. For example, one could use line of code counts or function points in estimating the length and scope of software projects. For architecture projects, you might use number of pages in the drawings or square feet planned as similar analogies. Every project has some gross measure of its size that is available at the outset and can be used to plan the overall project in addition to this method I’ve described of tracking time against the earliest phases.

So back to the story. We really blew it on estimating and bidding on that first project for Tivoli, but when the next one came around, we had data on the portion of the overall project that the requirements phase had taken up. This allowed us to use Grady’s ratio to predict overall project size, and we found that on this second project, we came up with a very accurate project estimate. This worked very well for all of the subsequent fixed-cost consulting work we did for Tivoli.

Partially due to the strength of the solution and how well it ran on IBM’s AIX operating system, Tivoli was able to eventually sell their company to IBM for 743 million dollars in 1995.

For a consultancy that is doing fixed-cost projects, this concept of using the standard ratio of requirements phase to overall project length is a very powerful project estimation technique. It can eliminate erroneous bidding and its resulting costs, which is a major concern for such companies.

Accurate Bidding

Overbidding on a consulting job means that you won’t get the work in the first place, because the potential customer will give it to your competitor at a cheaper price. Underbidding, however, means you will win the deal and lose money. Neither situation is acceptable for businesses today, and yet, most consultancies do a poor job in this area. One way to make more precise bids is to use a key performance indicator, which is a tool used to measure progress towards a strategic business goal. For example, the number you want to minimize in this situation is defined by the formula [(E-A)/E], where:

E = estimated hours to complete the project
A = actual hours spent to complete the project

It is important to keep this KPI value as close to zero as possible, which indicates that you are bidding on projects more accurately.

Just tracking this number is a great first step towards better bidding, and you can get the necessary data to calculate it from any timesheet system, including a paper one. Automated timesheet systems, however, are generally even more effective in this area because they often have reports to calculate the KPI figure for you.

Improving adherence to your estimate can be difficult for some companies until they understand the ratio concept described above. An example of this is illustrated in the following diagram, which shows how the formula can work for any business. Your company’s magic number may not be 6-8% like Grady’s, but once you determine your own ratio for specification to total project length, you can use it again and again.


Making it Work

I currently run a software company, Journyx, and I can assure you that this project estimation technique continues to be successfully employed by many of our customers to their great advantage. It is easy to implement and you can do it too. Once you do, you will start producing laser sharp estimates before you know it. And that’s a result we can all feel good about requiring.

Happy estimating!

Don’t forget to leave your comments below

Curt Finch is the CEO of Journyx. Journyx offers customers two solutions to reach the highest levels of profitability: Journyx Timesheet – a timesheet and expense management solution for the entire enterprise – and Journyx ProjectXecute – a solution that unites project and process planning with resource management. Journyx has thousands of customers worldwide and is the first and only company to establish Per Person/Per Project Profitability (P5), a proprietary process that enables customers to gather and analyze information to discover profit opportunities. Curt is an avid speaker and author, and recently published “All Your Money Won’t Another Minute Buy: Valuing Time as a Business Resource.” Curt authors a project management blog and you can follow him on Twitter.

Intentionally Incomplete

This is my initial blog for BA Times and I’m certainly happy to be joining the community. So, a little about me-

My name is Bob Galen and I’m from Cary, North Carolina. I’ve spent the greater part of 25 years in software development-in roles such as developer, manager, director, project manager, tester, and project manager.

For the past 10 years, I’ve been moving my thinking and practices towards those espoused to the Agile Methodologies. I’ve found them to be the most congruent, humane, and effective approaches for delivering software and I try to share my insights with everyone I meet.

Perspectives – you’ll see a strong skew in my blog posts related to the following topic areas:

  • Implications of software testing for the BA
  • Implications of agility for the BA
  • And leadership and soft skills topics for the BA

So that gives you a feeling for coming attractions. But, enough of that…

A key requirement artifact in the agile community is the User Story. Mike Cohn does a nice job of covering them in his User Stories Explained book. I may go into more definition later on the topic, but I wanted to explore one critical characteristic of the user story now. That characteristic is this –

The user story is intentionally incomplete. Yes, you heard me right. It’s ambiguous. It’s got glaring holes. It fosters questions…lots of them. Those questions come from different perspectives too. The developers will have a different set than the testers. Or the BA. Or the architects. Or even the ‘customer’.

What’s the point of having a requirement that is ill-defined? I’ll tell you. It’s to drive conversation surrounding each requirement from the host of different perspectives needed for their implementation. You see the questions are expected…in fact, demanded in agile teams. There’s the agile manifesto notion of “People and Collaboration over Process and Tools” and the user story is an initiator of this collaboration.

I think of it not as two-way collaboration, but multi-way collaboration. Minimally, when a team member picks up the user story for implementation, they gather in a triad of three primary roles-the development-centric, testing-centric, and business/customer-centric views. They discuss the details of the story from each of their perspectives and refine it.

Not only refine it, but leverage all of the knowledge gleaned so far from previous story development and project execution. That’s a key here. You defer specific definition realizing you’ll gain richer information with each Sprint or Iteration that you execute. So this “working software” knowledge is also spun into the evolution of each user story. Another driver for this is Lean’s Just-in-Time and Just Enough thinking when it comes to software development. It turns out that we’re often quite presumptuous in our software development efforts. We assume that we can predict the future in requirements or design of software or even our planning without first writing some of the software.

That approach perhaps works for simple or by-rote things, but not for complex applications or those that are new, novel, and competitive solutions to our customers’ problems.

For those of you struggling with this conversation-based requirement approach, I’ll leave you with a final thought. Have you ever seen a written requirement drive development and testing work that, when you pulled the two together, the code didn’t match the tests? Of course you have. I’ve seen this occur way too often. So while writing requirements is good and necessary, the user story is perhaps touching on an important but missing element in our requirement elaboration.

To be continued…

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected]

Seven Tips to Ensure Requirements Management Success

The path to building great software goes through requirements management.  It’s easy to forget some times, but the world relies on great software.  Software operates the cars we drive, the planes we fly in, the cell phones we can’t live without and the tools we use every day to get our jobs done.  Software is everywhere.

As a software professional, you know all too well that software development isn’t easy.  A software product is never completed.  There’s always an opportunity to improve functionality and there’s no shortage of challenges to overcome along the way:

  • Lots of people involved in the process
  • Customers have difficulty articulating their real needs
  • Requirements constantly change
  • Teams are spread across multiple geographies
  • There’s growing pressure to release products faster
  • The complexity of software doubles every 2-3 years
  • More projects fail than succeed

Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success.  And, the path to building great software goes through requirements management.  Organizations that embrace this concept enjoy greater results.  They experience fewer errors and frustration, faster planning and development cycles and they’re able to deliver higher quality products to their customers.

What You’ll Learn:  The goal of this article is to provide you seven essential tips to help you be more successful with requirements management.  For some, these tips might be new.  For others, these tips will serve as a good reminder of the fundamentals that are easy to lose sight of during the heat of a project. 

Tip #1. Stay Connected

You can eliminate most issues by keeping everyone connected.

Much attention is placed on the high failure rates of software projects, and for good reason.  Any time there’s billions of dollars at stake and failure rates ranging between 60%-80%, people are going to pay attention.  But, what you don’t hear as much about is the root cause.  Last year, in The State of Requirements Management Report we polled over 200 professionals about the top challenges they faced in eliminating project failure, and the resounding theme boiled down to one thing – communication.  If you can get connected and stay connected throughout the entire development process, you can eliminate the vast majority of issues.


Simple Definition


Keeping your entire team connected throughout the development process


Keeping all the requirements, artifacts and other related information connected

There are two parts to staying connected.  First, there’s the connectedness of your team, which has been popularized recently as “collaboration” – new buzzword, same meaning.  Analysts, project managers, developers, testers, product managers, executives, stakeholders and customers – is everyone on the same page about what you’re building and why?

Keeping everyone connected is often easier said than done, but it’s absolutely critical to the success of your project.  Depending on the size and location of your team, you can do this manually through meetings, phone calls and documents or you can use a tool to help keep your team connected.  It depends on your situation and the complexity of what you’re building.  See Tip #7 for the tipping points when a tool might be valuable.

Second, there’s traceability – the act of connecting up the requirements and other artifacts such as use cases, test cases, tasks, defects and even user documentation – all the details that are related to each other within a project.  For complex development projects, there can easily be hundreds or thousands of items involved and it’s critical to establish the traceability relationships between these items – both upstream and downstream.  

For example, when a high-level business requirement changes 30 days into a project, through trace relationships you can immediately assess the impact it has on any downstream functional requirements, tasks and defects that a developer or tester might be working on.  This helps minimize errors and costly rework because the team members affected are aware of the specific change and its impact.

Implementing traceability and a change control process that’s appropriate for your situation is one of the most important steps to ensuring success.  As a simple first step to establishing change control, you can use a change request form manually to document changes right now.

Tip #2. Take Action Now

Don’t wait for your process to be “perfect.” 

Doing something is better than nothing. It’s easy to fall victim to what you might call “process perfectitis” – a condition reached by teams that get paralyzed by process and analysis versus delivering working software.  How many times have you heard someone say, “Well, we’ll get to that project as soon as we really lock down our process? ”  Is any process perfect?  More importantly, should that really be your team’s highest goal? 

Whether your team is practicing some flavor of Agile or not, there’s one thing we can all take away from the principles of Agile – it’s that working software is the primary measure of progress.  Don’t get us wrong, optimizing your process is important, very important.  We’re constantly tweaking our process.  However, if you have a better process and no product, you still have nothing to show your customers.

Doing something is better than nothing.  Start small, identify a few critical requirements and take the approach of continuous improvement where you build, reflect, refine and repeat.  Then, with each release cycle you’ll learn more about the needs of your customers and continuously improve and expand upon the software solution you deliver to them.  If you think your team suffers from process perfectitis, look for these symptoms:

•·         Requirements definition phase seems to drag on and on and on

•·         In the last month more time when spent talking about process, while your product stayed the same

•·         Lack of a decision-maker to make the call when to move forward with development

Tip #3. Eliminate Ambiguity

Successful requirements management begins with writing good requirements.

One of the things you can do immediately is make a “do not use” word list and post it up on the walls in your office.  Visual reminders will help you to avoid using ambiguous terms when writing requirements.  Karl Wiegers, a well-respected requirements management consultant, in his book Software Requirements provides a good list of ambiguous terms to avoid in requirements specifications.  Here’s a snapshot of a few them.

Ambiguous Terms

Ways to Improve Them


Specify the minimum acceptable speed which the system performs some action.


Describe the ways in which the system must change in response to changing conditions or business needs.

acceptable, adequate

Define what constitutes acceptability and how the system can judge this.

simple, easy

Describe system characteristics that will achieve the customer’s needs and usability expectations.


Try to state requirements as positives, describing what the system will do, instead of what it won’t do.


Define how the system is to handle exceptions and respond to unexpected operating conditions.

Source:  Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003

Tip #4. Reconnect with Your Customer

You don’t have to be an expert to capture the voice of your customer – just committed.

This may sound obvious, but it’s easy to lose sight of customer needs as a project gets underway and the team gets to work building the solution.  Keep in mind, we use the word “customers” to refer the end-users of the product you’re building – these customers could be external consumers for commercial products or internal users in the case of internal IT systems where other departments and employees are your customers. 

Capturing the voice of the customer isn’t a one-time effort.  Most project teams do a thorough requirements gathering session at the beginning of a project, but rarely does the customer interaction carry through to the end.  Successful requirements management practices include constant communication with customers.  Otherwise you risk falling into the classic trap of delivering a product that end-users reject because it doesn’t resonate with how they expect to use it.

There’s definitely an art to eliciting feedback and requirements from customers and clearly some people are better at it than others.  There’s a plethora of books and courses out there to provide training for this specific skill.  However, you don’t need to be a requirements management expert to capture the voice of your customers. The fundamental skill required is commitment.  Commit to picking up the phone every week and talking to customers.  Commit to getting out of your office and sitting down with customers in their real environments.  These are things everyone on the team can do, and should do.  Even in Agile it’s not always possible to have an on-site customer present, so you have to commit to getting that feedback other ways.  

Here’s a quick list of Dos and Don’ts to follow as reminders for how to stay connected to your customers.



Be a journalist – ask open-ended questions

Think you know best what customers want

Talk to your customers every week

Assume past experience is representative of current needs

Be open and flexible to change

Assume customer needs are static

Just pick up the phone and call customers

Elicit requirements & feedback only at the start of a project

Listen with an open mind during elicitation

Sell customer on your idea for how a solution should work

Sit with a customer and watch how they work

Assume customers know how to articulate their exact needs

Close the loop with customers when their feedback has been implemented in the product

Forget to capture and share the evidence you gather with your team

Tip #5. Prioritize Objectively

Avoid building functionality that customers don’t need and may never use.

Development time is so valuable.  There’s nothing more frustrating for everyone than wasting time building features that customers don’t actually use and don’t provide value back to your company.

This is where requirements prioritization is essential.  You need to avoid the common pitfalls of building features that seem cool or that someone thought a customer might need.  Too often, requirements prioritization happens subjectively.  The team holds a meeting and in a debate over the requirements the loudest voice wins; or a request comes in from a salesperson who just spoke to a customer and the most top-of-mind request becomes the hottest priority du jour.  With each new feature request or high-level requirement, ask these questions to determine if this is a must-have or a nice-to-have feature:

  • What percentage of our customers will benefit from it?
  • Does it fit our brand values and enhance a competitive differentiator?
  • What is the trade-off if we prioritize this ahead of other requirements?

It’s best to establish an objective prioritization model that quantifies the variables that matter most and that each high-level requirement gets evaluated against.  That way, by getting agreement on the scoring model, it’s easier to get consensus on the highest priority requirements your team should focus on, objectively.

Tip #6. Minimize Overhead Select the right tools to get the job done.

If you’re a small team in the same office developing a fairly straight-forward product, you can use a whiteboard, task cards and daily face-to-face meetings to manage requirements.  A specialized tool in this case could create unnecessary overhead.  Likewise, if your team is building a product where the requirements are all agreed upon upfront and won’t change much throughout the course of development, then documents and periodic status meetings may work just fine. 

As projects grow in complexity and teams grow in size and geography, so do the communication challenges and overhead of trying to keep everyone and everything in sync.  It’s in these scenarios, where a requirements management tool can add value because the overhead of using the tool is far less than the manual overhead it takes to keep track of changes, manage trace relationships, update documents and communicate with everyone on the team.

Here’s a checklist of a few common tipping points where a specialized tool makes sense and can help reduce overhead by automating the process of keeping people and all the related information connected.


Tipping Point



The more complex the project, the greater the need.  If you have over 100 requirements.

72% of teams have projects that on average have 100+ requirements.

Team Size

The bigger the team, the greater the need.
If you have over 25 people involved.

Over 40% of teams have at least 25 members and stakeholders.


The more geographically distributed the team, the greater the need.  If 10%+ are virtual.

Over 60% of teams have at least 10% of their team working in different locations.


The more changes, the greater the need.  If you spend 10% or more of your time managing changes to requirements.

Over two-thirds of teams spend 10% or more of their time managing change.


If traceability is a priority for meeting standards or government regulation, a tool is valuable for automating the management of trace relationships, change control and version history.

Benchmarks:  The State of Requirements Management Report by Jama Software and Ravenflow, 2008

Tip #7. Don’t Reinvent the Wheel There are many existing templates and resources you can leverage right away.

Even though every company, project and team is unique, the resources needed to help you be successful, in most cases, already exist.  In minutes you can do a search on Google and find a wealth of best practices information.  As a starting point, here’s a link to more resources from Jama Software and Karl Wiegers for free companion resources to this article:

Eric Winquist is CEO and founder of Jama Software. In March 2006, Eric founded Jama with the vision of providing customers a more collaborative way to develop new products and eliminate the common frustrations with traditional approaches to requirements management. Eric is an accomplished entrepreneur, business analyst and project manager with over 14 years experience working with a wide range of organizations. Previous to Jama, Eric founded Redside Solutions, a software development consulting firm.

John Simpson is director of customer outreach, Jama Software. John represents the voice of the customer and leads Jama’s product strategy and communications.  John has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. He has contributed to several books, whitepapers and presentations.

They can both be reached through the following: 503.922.1058       [email protected]  I                                3/09


This is NOT another Agile Methodology posting.  I make no claims to any special agile expertise, nor am I interested in methodology wars.  I just want to say that fads are fads, and never substitute for analysis.  I completely understand the attraction to agile.  It is an excellent summary of what can work for some teams, on some projects.

It is my observation that all the named methodologies I have run into can map onto BABOK concepts, and the BABOK is a superset of them.   

Here is the manifesto itself for context (derived from the Agile organization’s own web site at ):

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

That is, while there is value in the items on
the right, we value the items on the left more.


And here is one analysis, based on general knowledge, personal experience and BABOK concepts:

  • BA Fundamentals (and hence the essential skills to perform Requirements Communication) have to be present before tools matter.  Tools can only support competent, effective behavior, not create it.  In a sense, all successful projects are “agile” – it is my observation that all successful projects are full of brilliant individuals who interact fast and freely.  This single factor seems to compensate for everything else – counterexamples are welcome, I don’t have any.
  • Software over documentation is already the most common approach in software development, so it is hard to understand why it matters to “Agile”.  Since 65% “failure” rates are already being achieved in software development, it must be items 1, 3 and 4 that really matter, if Agile is effective at all.
  • Substitute “Iteration of Requirements with Stakeholders” for “Customer Collaboration”, and substitute “waterfall requirements” for “contract”.   Contracts, at their worst, are an attempt to “lock in requirements” before they are understood, leading to excess change order profits for the contractor (when changes are allowed), or failed stakeholder acceptance (when they are not).  Waterfall requirements are best saved for “one shot” efforts like the moon program.
  • Over planning, and reluctance to adjust plans as requirements are “learned”, is clearly a cause of certain project failures – it is mostly a failure of intelligence (see item 1).  What is missing from this concept is the idea of Enterprise Analysis (especially risk analysis, stakeholder analysis, and cost benefit analysis) and the Requirements Planning that must follow from these.  Another way to put this is – IF the project is simple and low risk enough, Agile may be a fit (see BOK tables 3.0 and 4.0 in the Enterprise Analysis section, and see if you can spot which projects might use Agile.

SO, from analysis to opinion (if you have your own opinion, send it in, we will tally responses and report on same):

IN MY OPINION:  Agile process fits certain kinds of projects, but hardly most.  Here is my list – what is yours?

“Small potatoes” – low risk, decent to high payback systems that only have to satisfy a small number of users with homogeneous interests, have low visibility, or represent proven, successful increments to already successful systems (yes, maintenance and enhancement).

 “Feasibility” or “Proof of Concept” trials, which could clear the way for more investment in a larger project?

 “Research” projects, where almost all is unknown, budgets are huge, and the paybacks considered indispensable, if they can be achieved at all.  These are really rare; one example was the “skunkworks” team that developed the unique (and ultimately unsustainable) Blackbird spy plane.

“Invention” projects for systems that can succeed “virally” and evolve, that represent completely new behaviors ,or huge boosters to behaviors, that people crave, regardless of how poorly delivered (e.g., cell phone service, social networking, 45rpm records).

WHAT AGILE PROBABLY DOESN”T DO is Enterprise level projects, projects that must organize the efforts of many people.  I am sorry to say that I hold this opinion in spite of the fact that I helped lead just such a success – an Investigation Management system for over 1400 government users.  We succeeded by using all four principles in the Agile Manifesto, AND this only worked because we were an A-1, Agile Item 1 team.

My advice – get the smartest team you can that actually CARES about their work, and put them under tremendous pressure – they will cut to the bone, and will NOT skip any critical steps, and you can call it Agile if you want, but I call it B.A.gile!

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!