Over the past few years I have led a large number of workshops on software requirements and project management. Through these workshops I have had a number of very interesting discussions with participants. A theme keeps recurring time and time again in the conversations "How do I apply these ideas back in my workplace?"
I've often given thought to these questions, since I remember my own experiences many years back as a practitioner on a project team. We used to dread when the project engineer went off on a course. They'd come back pumped full of enthusiasm, with a bag full of books and handouts. We'd often be stumped with the challenge of how to translate the nice neat idea that worked so well for controlling stop lights to now make it manage radar tracks. As always, it was quite a stretch.
Just last week the question came up again in a hands-on workshop I was leading on how to write good requirements. During a break a student produced several pages photocopied from a book by a well-known author. The dilemma? The author listed several well-accepted techniques for modeling requirements, discussed them in some detail - but was completely silent about providing useful advice as to when and where you might consider using them and which type of project they would be best-suited for.
I think there is a yawning gap that is largely being ignored by authors, trainers and practitioners alike. The gap is how you transition from theory into practice - how to use these new ideas in the workplace. What is the best way to adopt the Use Case approach for requirements gathering? How should you go about implementing effective quality reviews? How do you get your organization to embrace the concept of collaborative requirements development?
Perhaps the gap is caused by practitioners who tend to be too quick to dismiss ideas and approaches. If something does not immediately work for you then simply keep on surfing to the next great idea and repeat until you find something that fits your way of thinking.
Perhaps the gap is caused by trainers, authors and their publishers and promoters who might be too keen to promote their latest writing, pronouncing it as the next 'silver bullet'. Even if the only thing that is new is a repacking of existing ideas as 'good practices' - anything that drives sales can't be bad ...
Perhaps the gap is caused by the software industry at large. There seems to be a current pre-occupation with 'templates', 'patterns' and the like. While these are valuable time-saving and quality enhancing techniques, an unfortunate side-effect is that they seem to instill in others (aka the pointy-haired boss) that it is now 'easy', a 'no-brainer'. The sad truth is that software requirements development was never easy and these approaches are encouraging the industry to look in the opposite direction from where they ought to be.
Perhaps the gap is caused by us all in not accepting the reality of today's workplace. Deep down we all want to work on something 'new'. A clean sheet where we can make our mark. The truth is that very few of us get that kind of opportunity. The vast majority of us are either maintaining existing software systems, or our project is to add some feature or capability to an existing system. In light of this, it is strange that so many of the industry's leading thinkers, writers, academics and gurus begin with the premise that the project is starting from scratch.
Whatever explanation sits best with your personal experiences it is my opinion that we need to do a better job of equipping practitioners with skills and techniques that they know how to apply in their workplace. On their own theory and looking at so called 'best practices' are not enough.
In short, practitioners need access to practical guidance on how they should apply the new practices they learned in the context of their everyday work. Without this guidance, most improvement efforts fail to live up to expectations and are discarded because "it didn't work for us': Unfortunately, the challenge we regularly face in our workplace is that there is no one available to provide this advice, or to whom we can turn to with questions. We are often left on our own trying to improve things by searching out books and courses for advice. But these often leave us feeling short-changed because they provide little guidance on how to bridge the ideas to the world of our project realities. Our experience over the years is that having access to knowledgeable experts as coaches or mentors greatly increases your chances of success. If such people are not available within your organization, using an external consultant is essential and results in a significant return on investment.
While we are at it, we need to provide enough time in our project schedules for "good requirements'; if not the right ones, to rise to the surface.
To get good requirements, both parties need to think about it. To put it another way, have you ever gone to the mall and bought something on impulse, a CD, clothing, or whatever - only to get it home to discover you don't really like it? The same concept happens in eliciting requirements, if you don't have the time to think about it, the results can be difficult to live with.
Too many times I see projects rigidly applying the 'duration = effort' equation when it comes to requirements. If it takes four weeks of effort to get requirements elicited and understood, we plan for four weeks in the schedule. Unfortunately it doesn't work that way. Talk to anyone in the requirements area and they will readily agree. However it's not really a topic that any of the well-known authors in the field address in any serious depth.
Reflected thought helps us get to what people really need. But to get there we need to slow down a bit. Heard of slow down in order to go fast? It really works when it comes to software requirements.
The last part of advice: We can't be instant experts. When it comes to software requirements, a good requirements analyst is not short on good judgment and wisdom. As I keep on telling attendees who come to my workshops, I wish I could equip you with these qualities by simply attending my course or even reading those requirements books by well-known authors. Unfortunately, neither I, nor anyone else can do that for you. The only way you develop them is by doing it, and reflecting on what you have learned from every experience. Good requirements analysts are made by doing requirements analysis, one project after another, and learning from experience.
Many people claim they can help by equipping you with theories and canned examples, but the best help is from those who can help you bridge the gap from theory to practice. By working on real examples that are closer to what you will find in your workplace, they can help you to determine what you need, and then select which of the many recommended methods and techniques seem to work best for your projects and workplace.
In the end have the courage to not just try some of these ideas on your projects, but to learn from your experiences and do it better next time.
Douglas Muir, PMp, is a Principal Consultant with Software Productivity Center Inc. in Vancouver, BC.
Last Updated: Wednesday, January 11, 2012; at 12:17:43 AM
|
Contact product support |
Log in to eSupport |
Toll free 866-778-3322 ext. 2 |
Next Steps |
Let us assist you in finding the solution that fits all of your needs. |
