John Carrillo Archive

My colleagues and I recently received almost 1,000 responses for a benchmark study on Application Lifecycle Management practices that we’re conducting. We’re now analyzing the data, but one thing is clear – one of IT’s top issues is requirements. In fact, our preliminary numbers show that almost half of all survey respondents reinvent the wheel when it comes to defining business requirements!  

The good news is that people are getting better. In fact, the International Institute of Business Analysts (IIBA) is just one example of an organization promoting best practices for requirements management. And on February 16, Serena will be participating in an IIBA webcast on requirements traceability. This should be a very enlightening webcast, as requirements experts will be sharing their experiences from the field. Serena will share how our customers have been experiencing increased satisfaction by looking at the entire requirements process and managing traceability from initial request all the way to release. I encourage you to register for the webcast on the IIBA website.

I recently had the good fortune to collaborate on a webinar discussion on requirements definition and management with Mary Gerush of Forrester Research, a thought leader in requirements management for many years. During the webinar, Mary and I outlined six key tips that organizations needed to follow in order to more quickly deliver higher quality products.

  1. Exploit the real requirements lifecycle: when looking at improving requirements, you should look at the entire requirements process – from initial request to release into production.
  2. Define and manage requirements collaboratively: your entire team needs to collaborate and focus on requirements quality – and that doesn’t mean testing.
  3. Increase your use of pictorial artifacts: you should use pictures to help drive better understanding of requirements.
  4. Establish a program of requirements reuse: reuse is critical to achieve economy of scale, especially across related products, applications and platforms.
  5. Take an adaptive, process-driven approach: tools alone won’t help you deliver better requirements – you need to think about people and process too.
  6. Measure and continuously improve: continuously measure business, project and end user metrics to determine if you’re really delivering quality requirements.

If you’re looking for expert advice on improving the quality of your products through good requirements practices, I highly encourage you to listen to our entire discussion on requirements management.

What is it about Microsoft Office? I’ve been in the requirements management space for over 20 years, and I still shake my head when I run into organizations that use Word and Excel to manage their requirements. In a recent poll, 68% of Serena Software customers said they use Office for requirements management, which is slightly lower than the industry average of 80%.  See complete poll results below.

RM Poll Graph

Why does Office continue to lure organizations?

  • It’s “free”: everyone already has a license on their computer.
  • Easy to use: everyone knows how to use Excel and Word.
  • Extreme flexibility: it’s easy to capture exactly what you want, how you want it with PowerPoint and Visio.

But those strengths are also Office’s biggest problems. Here are just some of the dangers with the Microsoft siren song:

  • It’s not really “free”: I’ve conducted many workshops where companies showed me how Office wasted millions in rework, communication errors, and delays.
  • Ad hoc communication: Communicating requirements is often done via email or SharePoint, and the lack of process often results in wasted workforce productivity.
  • The impact of change: if a customer changes a requirement, how do you communicate that change to all impacted projects?
  • Reinventing the wheel: it’s so hard to find something buried in thousands of Word and Excel documents, so it’s easier to just reinvent instead of reuse.

I continually preach against this insanity that circumvents the basics of a good requirements process, and I’ll continue doing so. If I do it enough, I hope one day that unsuspecting IT organizations will no longer be lured by the call of Microsoft Office’s requirements mediocrity.

John CarrilloJohn Carrillo is a thought leader in requirements management and application lifecycle management, with over 20 years experience in the commercial software and manufacturing industries. In his current role at Serena Software, he provides strategic counsel to organizations regarding technologies, process, and best practices for application. development and delivery.

Great applications – or “killer products” – don’t originate within and then emerge magically from development. Innovation properly emerges from development’s close and iterative engagement with customers and the business. Whether developers use an agile or hybrid approach, focusing on how to consistently deliver quality to the customer remains the single most important strategy for delighting customers. In fact, organizations that effectively manage their requirements process deliver 75% more customer requirements, develop projects 161% faster, and reduce development costs by 75% (IAG Consulting).  Staying focused on requirements also helps drive software quality, further helping delight customers. It’s safe to say that after all these years, the old adage about quality still holds true: “The quality of your product is directly related to the quality of your requirements.”

But if requirements are so critical, why do so many organizations do such a poor job at managing them? Why have decades-old tools failed to resolve the problem? And why has agile still had limited success across the enterprise despite “light” management of requirements?

The unfortunate truth is that many of the tools that were originally designed to help developers manage requirements are actually responsible for holding them back from delivering on customer requirements. According to Forrester, “Application development and program management professionals searching for the right requirements management solution often get tripped up by ambition…This leads them to purchase a tool that’s more complex, more difficult to use, and more expensive than is necessary.”

Development organizations also sometimes get stuck in a feature-function analysis focused solely on “requirements management” that includes factors such as baselining, versioning, linking, and traceability, while ignoring the broader lifecycle of everything they need to do to capture requirements, understand their complexity and impact, and validate features. Instead of focusing solely on “requirements management,” often the best solution to development’s problems is looking at the entire process and how it’s impacted by change.