For the last four years, I have been working with a very large government organization on a variety of testing projects.  This experience has changed much of the way I look at and think about testing.

When I first started in software QA, I was one of the “We are the gatekeepers of quality!” kinds of people, considering myself the last vanguard before unleashing unclean software upon an unwitting world.  I eventually gave up that belief, and came to a place where I viewed testing as an information service, providing timely and accurate information to management concerning the quality of a piece of software.  Whether or not that software got released was a business decision, and the current state of quality was only one of many considerations that went into that decision.  Then I became a member of the Context Driven school of testing.  And then I came to work here.

Now, in the time that I have worked here, I have seen a lot of good work done.  I have done a lot of good exploratory testing, I have even gotten to do exploratory load testing, and I have stopped a lot of bad software from landing in users hands, which ultimately is job satisfaction of a kind for us testers.  But I have also seen at least three different projects go incredibly bad, and when a government project of the size and scope we work on here goes bad, it goes really BAD.  Estimates of the cost in dollars are millions…not quite a bank bailout, but still pretty serious coin.

As I have looked around and tried to understand what causes these collossal failures, I have come to the conclusion that it is not just bad testing.  It is not just bad development.  It is not just bad program management.  I think it is a series of events that is almost a natural outcome of organizations that become this large.  Projects become interdependant;  communication through the cloud of beauracracy is unclear;  people come and go;  with almost inexhuastable resources, and very lax accountability, mediocrity sets in;  and one day, you wake up with two projects that seem to work fine independantly, but won’t talk to each other, yet are interdependant in the real world.  Welcome to the brave new frontier of Systems instead of Applications.  Soon after, the finger pointing begins, everyone circles the wagons, and both projects proceed to fall out of the sky and become grey smoking holes in the ground.  The casualty count is high.

So given that, how do I try to make things better?  This question has led me to a new field of study, and a new era in my continued professional development;  I, and my company, are now beginning to get involved in Scope Management.  Scope managers are not common, per se, in American organizations, although they have been gaining prominance for the last decade in other places such as Finland, The Netherlands, and Australia.  A scope manager is essentially a mediator between the various consumers and producers of IT products in an organization.  The skills involved come from diverse set of more commonly understood professions;  Development, Project Management, Business Analyst, Customer Advocate, and Quality Assurance Engineer.  Strong analytical skills as well as strong communication skills are essential.  If you have been an independent consultant for any amount of time and with some measure of success, you likely have all of these skills.

So why do I think a scope manager can make a difference, when a tester cannot?  Two reasons;  First, they answer a different set of questions, e.g. “How do we all, all stakeholders, define this project”  and “How do we monitor the evolution of this project and keep our discreet definitions in synch?”  Second, they function at a much higher level, where the input carries more weight, and is less likely to get lost in the local politics.  A scope manager never blames anyone for anything…he simply states truth and reality, and presents options;  management then makes choices.

Now, some will say, this is a very document heavy, process heavy thing; you have sold your soul and are no longer context driven;  to them I would say, you are partially right.  This can be, and likely will be, relatively process and document heavy.  But these last four years have taught me that that is simply the reality of the world, in some contexts…see, still context driven.  Context driven does not say document heavy and process heavy are always bad…it says there are no best practices, nor are there any worst practices…just practices that work better in some instances than others.  Think of it this way;  if you are out on the lake on your personal boat on bright summer day, and the boat starts leaking, process and documentation may not be important;  you have a few choices, including simply jumping over and swimming the 50 yards to shore.  But if you are on an oceanliner in the middle of winter miles from anything but more water and that ship starts leaking, wouldn’t you prefer that there was some documentation and process to keep you safe?  Size seems to shift the context that way…so I would not think a startup dot com would see value in scope management.  But huge organizations, like my current client, will.

Also, I am getting in on the ground floor more or less, and talking with some of the influential folks in the industry, and we have already begun to discuss how we may try to adjust the basic process into a variant designed with more agile organizations in mind.  And so I am excited about the opportunities ahead, and the chance to try and continue to make a positive difference.

If you are interested in Scope Management, and the training and services we will be providing, please visit our website for more information, and feel free to leave comments here about what you think of this new emerging concept.

David