31 January 2011

Requirement or Design?

Buckminster Fuller blueprintphoto © 2005 Andrew Kuchling | more info (via: Wylio)
The last few years as a BA, I've become increasingly convinced of the necessity of mockups, or better yet high-fidelity simulations, in order to effectively elicit requirements. Yes, text based requirements are still a main-stay and process documentation is routinely needed, but when it comes to requirements for a system implementation, being able to show your stakeholders exactly what will happen is simply a must.

Its because of this realization that sites like Service Design Tools strike such a chord whenever they appear in my news feed. I think the Business Analysis community and the User Experience community have both come to the realization that both disciplines are necessary if we're ever going to create applications that meet our users needs and do so in the condensed timelines that our business partners are increasingly needing.

I love that this site gives you different suggestions for ways to communicate a design, which is nothing more than a visual representation of requirements, to different types of users and stakeholders. Not all of us 'get' requirements in the same way, but these generalizations help us tell the story in such a way that we are most likely to get the message through to our target audience.

The other thing that I think is just great about the site is its ability to inspire me to try out new techniques that are not in my current toolkit. I've never created a Moodboard nor have I created a Customer Journey Map. Sure, many of these techniques would never work in my organization, but the sheer volume of options suggests that there are at least a few items here that might work for me. I can't wait to try a few of these out on my next project.

28 January 2011

27 January 2011

BASF: Lessons From German Marketing

Back in the late 1980s and early 1990s, the German chemical company BASF ran an ad campaign with the slogan, "At BASF, we don't make a lot of the products you buy, we make a lot of the products you buy better." It was, in my opinion, an ingenious set of ads, an example of which you can see below:

There are a couple of things that really stand out to me about these commercials, all of which apply to work done by BAs, PMs and Testers. In the rest of this post, I'll use the above commercial as a jumping off point to bring out a few of these points.

First up, we're not the finished product. PMs create project schedules and budgets, none of which mean anything except as a plan to reach a goal. BAs manage requirement efforts, none of which mean anything unless the requirements are turned into a solution. Testers ensure that what the stakeholder wanted is what was delivered, which can't happen unless something is created. BASF doesn't make airplanes, lotion or carpet, but without BASF, those products would not be nearly as valuable to us.

I also see that its sometimes easier to define yourself in terms of what you don't do. BASF does a lot of things, but in the end, what it doesn't do is make direct to consumer goods but enhances the goods consumers do purchase. Its often difficult for people who don't have a good grasp of chemistry to understand the difference that BASF's products make in each of our lives. In my job, I don't turn in below quality work products, I don't turn them in late and I most especially don't disappoint my customers with an inability to deliver.

Next, emotional connections should not be overlooked. When you consider BASF's actual products: dyes, soda, sulfuric acid, ammonia, plastics, etc, you start to realize that the company doesn't sell much of anything a consumer would want to purchase directly. So why would BASF want to market directly to consumers with such an emotional appeal if it doesn't actually tell anything about what the company actually makes?

If BASF can get the customer to think about buying more airplanes, lotion and carpet, then end product producers will need to purchase more of BASF's products. They're essentially asking customers to pull their products through a channel. When you've got a product that isn't something that sounds easy to sell, falling back on emotion is a great way to get your message through.

This is a concept I rely on when ever I need to tell someone about my work as a Business Analyst. Both words in my title are fairly common, but the combination of them in a title seems to outsiders a bit odd. I know this by the crinkled looks of confusion people sometimes give me when I try to tell them what I do. I could talk about how I elicit, analyze and document requirements, how I translate business needs into solutions or how I help the testing team ensure that the solution met the customers needs. I've tried, and you know what I got? More confused looks. Eventually, I hit on a solution.

Now, whenever anyone gets that weird look on their face upon hearing my title, I follow up with an emotional appeal. My one sentence job description is that "I make people's jobs better by changing the work they do or the computer system they use." That, clicks every time. If they want more detail, I start asking them about things that frustrate them about their computer, or about common frustrations we all share, like hanging out in the waiting room with a bunch of sick people all trying to see the doctor at the same time. I then explain how its my job to find out how these systems are broken and offer up suggestions on how to make life less frustrating to everyone.

And that brings up my last lesson from the commercial, we help people, systems and processes get better. No, I'm not saying we have the deep impact on people's lives that their doctors, therapists or firemen do, but we have a small impact on a lot more broad of a population. The work I do at my current job impacts in the neighborhood of 60,000 employees every single week and millions of customers every single year. Our company runs quite lean in the development and support areas, so a small number of us have a large impact on a medium group of people and a small impact on a really huge group of people.

So what about you? What did you take away from that BASF commercial?

26 January 2011

Jama Contour reviewed

Last week I told you that I trialled Jama's Contour Requirements Management tool and that I liked it. Today I want to share more detail about the experience. So here it is; the good, the not so good and what I think are the main areas for improvement.

What I liked

Within 15 minutes and with no checking the help files I was able to get a project started. Overall, I found the process of downloading Contour and setting it up to be very straightforward. The user interfaces are relatively clean and simple. A problem I have with many all-purpose-all-singing-all-dancing applications is that there are too many options when you hit that first screen.

The container model for managing requirements is both easy to understand and to use. I was very happy with the ease and simplicity of re-arranging my modelling of requirements. For example, I had created a set of entity oriented domains and drilled into them. At a certain point I was reviewing them and started to re-orient the requirements toward a functional model. For example I started dragging & dropping all the search and report requirements from all over the requirements model into one space under a new “Search and Reporting” container.

I also liked the way I could swap the requirements approach mid stride. I had started with User Stories as the way I was going to do the work, but quickly I decided that use cases would be better for this job. It was no trouble to simply select and change the requirements I had worked on and then to re-structure the relationships by dragging the children type requirements across to the parents.

Did I mention dragging and dropping? It may sound basic these days, but the ability to drag and drop items in a web application for enterprises is still novel to me. It’s so much easier than having to fiddle with various menus and arcane administration functions.

Performance? There was a slight lag as my 5 year old Toshiba Satellite tried to process requests. Especially once the number of requirements toped 500. If it was hosted on either a late model computer or network server it would be much smoother. I have also recently used the web hosted version and found it flies compared to local hosting. Thinking about cloud solutions in general, I have to say I’d recommend the hosted Contour service over the local one for so many reasons, including DR and vendor support.

I did not use the review feature at all, as I was working alone, but there is a neat tool in there to manage peer and stakeholder review of requirements. You can send messages to people to review your work on the fly while you move onto documenting the next requirement. The collaboration features look cool and I am interested in exploring them further next time.

Contour also has the ability to baseline a requirements set, and to assign estimates. So it could be used as a tool to manage project schedules, producing burn down charts and similar reports.

Additionally traceability is well catered for. You can track the requirements through different phases, backwards and forwards in Contour as well as dependencies across requirements. It also has an API to several popular test tools and you can always import/export via XML for others.

In 5 days I went from zero documentation and no RM tool to having Contour downloaded, set up and 90% of the requirements done. (I had to do some more work with people on the finance set of requirements before we could lock that one down.)

What wasn’t so great

Contour can export requirements to various file formats and it comes with some pre-defined Word and Excel export templates. I stumbled with this. The pre-installed templates are sufficient, but didn’t go the distance for me. I had to go to Word and fiddle around with the document layout – doing things like numbering headings and changing paragraph indentation to make the hierarchy of requirements more transparent. Speaking with the Jama guys, they are talking about improving or extending the default template options.

Creating your own export templates is a bit arcane as well. I had a go, got stuck very quickly and then gave up. The help files were not any real help to me while I was under time pressure. (I was on a deadline and managing the format changes in Word was familiar and do-able.)

At one stage, to better fit the language of the document with the jargon of the client I had to change the word “system” to “application” which probably occurred in about 70% of requirements descriptions! There is no global find and replace. You can do this pretty simply via browser settings and CTL+V inside each requirements statement, but there was nothing there for the global change. If you have a data dictionary, be sure you lock down key terms before you go deep into documenting requirements.

A neat feature that I would have liked to use more is tags. Tags like the ones that categorize blog posts here re available, but editing tags was not a simple task. I understand you have to go to an admin screen and start mucking about in the system’s back office. Too hard. I am guessing this was a good idea back in the early days but that customers aren’t using it much, so it hasn’t been matured as much as the other features.

If this were my product I would do a couple of things

Firstly I’d up the release frequency and push out new features faster (but I’d recommend that to almost anyone.)

Secondly I’d invest time into the following features to bring it up to where *I* want it for *me*, today.

  • Global Find and replace
  • New export templates (and better help for setting them up)
  • Wizards (or similar) for when you first want to set-up or use advanced features

So there you have it. All in all it’s a very good product that can help project and IT teams increase their performance right away. If you are looking for a tool go get the free trial version and have a go playing with it. And come back here and share your experience and opinions in our comments.

This is *not* a Business Analyst Role!

There we were having a nice conversation about the value of business analysts when BAM...

24 January 2011

Google Chrome and the Release Cycle

Google Chrome Logophoto © 2008 Randy Z | more info (via: Wylio)
Back when Google Chrome debuted, I thought it an interesting concept, but not something I would ever use. I was a Firefox diehard. I was one of the few who could (or at least would) admit to never having willingly used IE. Even during the dark days of IE dominance, when Netscape 4.76 was the only competition in the land, I still refused to move over to the spinning 'E'.

So, one year ago, when Chrome gained extensions on the Mac, I decided I would spend one month testing to see if it was usable. That one month has very quickly turned into one year. Despite the great leap forward Firefox 4 is showing to be during its beta period, I still don't see myself returning to it anytime soon. The release management differences between the two competing browsers is, in my opinion, a lens into my reasons for switching.

Back in July of last year, when Google announced that it would speed up the Chrome release cycle to a new version every 6 months, I was at first incredulous and secondly, I thought it preposterous. Really? What kind of major coding could you get done in 6 weeks that would necessitate an increase in a major version number? It wasn't until I came across this set of slides that I came to understand the answers to my questions:
Chrome Release Cycle 12-16-2010

Reading through the problem, I can see why they moved to the cycle they did. I can't say I blame them as the end of a release cycle is always fast and furious. We tell ourselves, never again will we do this, yet a few months later, we find ourselves doing the exact same thing.

The decision to focus on features and not on release numbers or date driven development is impressive, but sadly probably not an option for most of us who are not Google. I don't think that most non-IT management, and even a lot of IT management, really gets what its like to work a well-run development cycle. It is hard, but giving them a solid date and a version number gives many of them a false sense of understanding because numbers and dates are something they 'get'. If we tell them we have a plan for delivering v17.9 on January 31, then that's great, right? Well, maybe.

But what about that line that discusses disabling features with a single, small patch? This I like. I always wondered how features that take months to develop could be held safely during all that time. If a developer kept all that code on their local drive, which then had a failure the day prior to completion, all that work would be wiped out. Sure, private branches in version control systems could be used, but they clutter up your system with a bunch of dead branches once you're not using them any more.

Another advantage I see is that by doing this, you force the developers to keep dependencies between code modules at a minimum. If any feature can conceivably be disabled with a single patch, you ensure a better, more maintainable architecture on your application.

The last thing that stood out to me was really a question. If you move to 6 week upgrade cycles, why do you really need a version number at all? Sure, its easier for us as humans to remember 'v17.9' than it is a build number output by some compiler, but really, does a version number matter at this point?

From a purely logical standpoint, I don't think it does. Google could still put out a press release every couple of months touting a new release of Chrome that includes feature XXXX or decreases page load time by 17%. They don't need to specify a version number, just that 'you'll be getting it soon'. For the 'About' page in the browser, you just need to know if you're 'up to date with the latest browser version' or if you need to do an update.

Sure, you can say that having v17.9 sound more advanced than having v2.7, but versioning has always been at best an art and at worst, a marketing farce. I am just beginning to wonder if we shouldn't start working towards the 'post release number' era. I don't see that they provide much worth in the modern world.

22 January 2011

(n(n − 1) / 2) Rn - the complexity of requirements workshops

Alex Papworth is running an online training session for business analysts and the discussion has turned to the challenges of workshops. Many feel the workshop format is inherently difficult (which I agree with.) I wanted to make a point and so put this together to help clarify my ideas.

Workshop complexity is the same as the Fred Brooks's Mythical Man Month, although I think a requirements workshop is even more complex as you have to address multiple issues in one session.  This leads me to add another element to Fred's model;

   (n(n − 1) / 2) Rn

Where Rn is the number of requirements being handled in the session.

Take a look.

My BA World 2011 Proposal is in

I have submitted a presentation for the BA World and PMOZ conferences this year. The BA World version is titled "Requirements and Project Scope. Managing requirements to achieve project success."

The story is around how measuring requirements variations will help you in two ways; you'll better understand  the likely project scope change cross your project portfolio, and you'll be able to spot requirements churn and take appropriate action.

I chose the topic because I wanted to better understand it.  I already have books on order from Capers Jones, Mike Cohn and others.  I also have a couple of case studies and I am in the process of asking RM tool vendors if they have data they can share. Anything you guys care to recommend to me?

Also - I am particularly excited as I signed up to the Bangalore BA World in addition to the Australian ones.  I hope my paper gets accepted and I get to go visit the city.

Requirements change over time. Any project that runs over significant time will have it's requirements change. Stakeholders and analysts learn more about the problem at hand, gain a better understanding of the product being developed or need to respond to a changing context.

How can you manage and measure your requirements so that you anticipate change and advise your project team mates and stakeholders of what is to come?

Come along, listen to this talk and then we'll run some exercises to help you understand the techniques involved.

By the way, your project sponsor and project manager will love you after you've adopted these techniques.

21 January 2011

Best Resources for QA?

Testing 1, 2, 3photo © 2006 alisdair | more info (via: Wylio)
The last month has just been a whirlwind. Between missing six days of work for illness, having 2 days off for holidays and being promoted, its been a lot to handle.

Wait, did I just say I got a promotion? Yes, its true. My boss has seen fit to promote me to a full manager and give me responsibility over all the analysts, both BA and QA. Now, I have six employees and three contractors for a total of 9 direct reports. I'm responsible for not only the requirements for a few different systems, I'm now responsible for the testing of over half of our internal systems. That's going to be quite a bit of work!

I tell you all of this not cause I'm seeking out congratulations, but because I'd like some help from our regular readers, some of whom I hope have lead QA teams in the past and are willing to give me some resources and insights. I've never been part of a QA team, although I've lead testing efforts for years as a BA. (Yes, according to the BABOK, testing is not a BA function, but rare is the BA who doesn't have to do that in some capacity.)

I'm looking for good material, be they books, websites, etc, about leading QA. Also, if you have general comments you'd like to leave with suggestions you have, do so in the comments as well. Looking forward to all the good advice you guys have!

20 January 2011

Two levers for performance improvement


Aaron Erickson asks why software projects cost so much and provides an answer; two inappropriately applied management levers.

The summary of the argument is;
  • People focus on cost per hour rather than total cost of the project, and
  • Process compliance activities are an impediment rather than as an enabler.
Aaron argues the second point a bit weakly, calling upon the straw-man that CMMI style process just slows down developers.  While I agree the sentiment is right it needs elaboration because the logic that is presented is wrong.

Let me put these two points to you;
  • Process is useful, but it's utility decreases the better your team gets.  
  • Process control is often misapplied
The better your team gets...
A super triple A team member on a Super A team that have worked together successfully for 5 years needs no process manual.  She knows exactly what everyone is doing at all time.  Osmotic communication is always in play. Work cycles are only hours long.  Everything is tested and validated continuously and the team are well linked into the client so feedback is coming into the team early and often.   When  new people join this team they don't need much in the way of process guides.  They are inducted into the team rituals and methods and the invisible process is imparted unconsciously.

On the other hand when we form up a new team from a combination of people with a range of skills and 
experience ranging from "my first job" to "grizzled veteran" you need some tools to bring them together.  Process is one of the potential tools at your disposal.

(A segue: I remember hearing it argued that scrum was not a process; that it's a framework.  Maybe that was positioning it as a counterpoint to processes that are poorly implemented and executed, but I am pretty sure it's a process.)

...is misapplied
Process is supposed to be an enabler.  It is aimed at benefiting both the individuals and the team on the one hand and the organisation on the other.  The benefits to individuals and teams is addressed in the scenario described above.  The benefit to the organisation is vitally important to the health of your organisation and project performance. As an organisation you all need to work together in a coherent manner.

People are often railing at the failure of optimizing parts at the expense of the whole.  Optimizing a team at the expense of a whole organisation is another aspect of this.  Sure you may use a team to pilot new processes, or even to test hypotheses, but teams should generally be performing in a consistent way.

Another way of looking at this is when you consider various parts of the organisational machine working together.  Some parts move faster or slower than others.  You need mediating tools to enable them to connect effectively.  (Think of process as an interface between application functions.)

The problems we encounter all over the place is where process is poorly understood and misapplied.  Two examples that come to mind about poor application of process are (a) lack of knowledge, and (b) managing personal agendas.  The later scenario is "politics" and there is so much that has already and will be said about that topic so I'll ignore it for now, but the first point - understanding process - is something we can all do something about. 

Take the time to learn the reasons behind process steps, understand and share your understanding with others.

There is more that can be done, including streamlining and changing processes, but learning and sharing is an excellent actionable first step.  Process isn't your enemy.  It's a tool.  Learn to use it and you'll have the benefit of another tool.  Fail to learn to use process to your advantage and you are shortchanging your potential.

19 January 2011

I tried Jama Contour and I liked it

Seven Exposures of the Singapore Skyline

Late last year I had a short engagement to prepare some business requirements to be delivered as part of a tendering process for a new enterprise application. The client enterprise is opening a new division and seeks an enterprise application to manage clients, assets and the related business processes and reporting to support growth in a new industry.

I as working remotely from the client and the rest of the project team and in three weeks I needed to get a reasonable draft back to the client reflecting what they wanted. During the three weeks I had a half day workshop and all the access I wanted to the project manager. He then did the leg work to chase down the information I needed with the various stakeholders.

Given the time constraints and the fact that I was going to have to iterate the requirements specification several times I knew I couldn’t do the job with the typical MS requirements tools of Vision, Word and Excel. Things were going to move to fast and I was going to change things too often. I had to operate efficiently and didn’t want to deal with the document management overhead.

I searched for Requirements Management tools online and looked for something that I could use and that was free. I expected that at the end of three weeks I would be producing the final document and then either walking away from the project or making a call with the project manager about buying whatever tool it was I was using.

I looked at a few, but the first one I stopped at was Jama’s Contour. For a couple of reasons; firstly I had just received an email telling me about a product upgrade and secondly because John Simpson of Jama has been a regular correspondent over the years in the project blog world, so I had a tenuous relationship established.

The three weeks is up by now, and the trial version I downloaded has closed down. The project continues and we are likely to procure access to Jama’s hosted solution for the next phase of the project (post tender evaluation.)

I liked it. Even though it is not yet what I’d call a complete product it has some great features and is continuing to grow. The best thing about it is that it I really easy to pick up and use straight way. While you can get some, training is largely unnecessary.

Having said that, this blog is getting on, so I’m going to defer a full review until next week. In the meantime, if you have any questions, drop them into the comments below and I’ll have a go at answering them.

Disclaimer: I have not received any financial incentive or reward for this review.  The views expressed are mine based on my experience of the product's free trial.

18 January 2011

The Enterprise Reset

Hurricane Katrinaphoto © 2005 NASA Goddard Space Flight Center | more info (via: Wylio)
Imagine if you will a natural disaster, be it earthquake, fire, flood or whatever, hits your company and completely wipes out your enterprise architecture. After everyone sorts out whatever remains of their personal life and returns to work, what do you do? You've got a clean slate. Nature has hit the reset button for you.

(For those of you who work in large corporations who are fortunate enough to not contain your entire operation in a single building, pretend you're a medium size business without a distributed environment to build upon. Or, if you wish, pretend your enterprise baggage can be tossed without anyone noticing!)

My thoughts:

Disaster planning has taught me that the first things to focus on are the critical items; those things that you need to run your business. You can suffer with manual processes and little automation for a short period of time, but there are some things so vital you must have them. Make a list of these items and get to work on them.

Once the critical systems are up and running, consider what you do and do not need to replace. If you've been wanting to do a process reengineering project to consolidate 3 antique systems into a single modern application you've already purchased but are only using a small fraction of, don't put the old pieces back in place. Install the new one and build from that better foundation.

Don't forget that its not all about systems. Some of your stakeholders probably lost a lot of valuable, needed historical documentation during the disaster. Now is probably the time to start up that offsite, electronic document store and buy a few industrial scanners so that the paper isn't stacked up all over the office but becomes a digital repository that can't be destroyed by a single disaster.

What about the location of resources? You're going to need a place to house everyone while you rebuild. Maybe its a time to consider not rebuilding, or at least not rebuilding as much. If the business location was destroyed, but your employees live in areas that were unaffected, maybe its time to start telecommuting or at least creating smaller, satellite offices.

Those are my thoughts. What about yours? Do any of you have a disaster recovery plan (especially those of you who work for smaller organizations)?

13 January 2011

Globish: English for the rest of the world?

Globish.com I've blogged a few times in the past about my very first project, a global CRM implementation that replaced 20 different systems with a single instance of a single application to serve the entire service division of a Fortune 500 company. It was an ambitions project, one that did eventually work, but it took a long time to get there.
One of the hurdles that project had to overcome was language. The company was headquartered here in the US, so English was the language used to communicate for most project purposes. When the project team members from around the world came together to talk, we did so in English. We were quite fortunate to have many of the non-US based team members who had either worked or lived part of their lives here in the US.

But there were several team members who spoke only enough English to reach a minimum level of functional communication during team discussions. True, their English was light years above my ability to speak their native languages (which is zero as I speak no other language but English), but had their English been more fluent (or my French/Spanish/German/etc been fluent), it would have meant many fewer struggles to bridge that communication gap.

Because of this project, the concept of Globish really spoke to me. English is not an easy language to learn. Its irregular, has an absurd number of exceptions to every rule and probably worst of all, those of us who speak it use an even more absurd number of idioms to 'enhance' what we say. Check out the video for more information:

What about you guys who work on international teams? Would a minimum set of words and with a simplified sentence structure make communication easier for you?

12 January 2011

Some risks are highly improbably but potentially devastating

Disasters happen all over the world.  This week Queensland in Australia is being flooded. The devastation will be huge for some, but overall the cities will recover much more quickly than smaller towns because of things like risk planning.

It may seem like a waste sometimes, but every now and again there are days when it pays off.

More on the floods.

10 January 2011

The Checkout Line: Why is it so slow?

Target, Checkout Linephoto © 2008 The Consumerist | more info (via: Wylio)
My wife and I have a running joke that if you want to spend a long time waiting around to leave the grocery store, you let her pick the line. Its uncanny that nearly every time we decide to not use the self-checkout, we get stuck behind the person who picked up 14 items without barcodes or in the line with the cashier who has decided to work at 1/4 speed this day.

Given that my day job is to manage requirements for a point of sale system, the time spent waiting in line at the store ends up being rather ironic, but it does force me to think about what motions and systems work well and which ones could stand to be improved.

This is why the following video on Queuing Theory was so interesting to me:

The part of this video that stood out most to me was the most efficient way to lay out a checkout line, with a single line feeding multiple registers, was also the most emotionally frustrating way for customers.  I know that when I'm standing in line for a roller coaster, with one massing long line up until you reach the station where that one line breaks up into a dozen small lines for each car, that the long line frustrates me, but that frustration goes away when i can pick my own short line.

I think there are some good applications to projects, especially when it comes to release management. Consider the situation where two stakeholders come to you with different problems. You know that in your next release, you have enough open resources to fulfill one of the requests, but not both. There are a couple ways you could consider to figuring out which you fulfill and which must wait.

You could use first in first out (FIFO) methodology and pick whichever request reached you first. This fails to take into consideration the severity of the problems. If both requests took the same time to develop, but one would bring in double the revenue of the other, then wouldn't it make more sense to do the one with larger revenue first?

But what if the one that would make less revenue has an impact to a government contract which must be in place due to a legal requirement? In this situation, no matter the revenue implication, the regulatory requirement would like get pushed to the front of the line.

So what method does your team take to 'queuing' up items for the next release?

7 January 2011

The 7 Stages of Project Manager Expertise

Last month I shared with you the results of a meeting I had with Shim investigating a model of bloggers as mentors.  He shared his perspective on Quantum Leap.

On his blog her references an article from 1998 called "The seven stages of expertise in software engineering" in which the author (Meilir Page-Jones) reflects on some lessons about why their consultancy can't get clients to stick with disciplined approaches to software engineering.

The seven levels in tis article are
  • Innocent, 
  • Exposed, 
  • Apprentice, 
  • Practitioner,
  • Journeyman, 
  • Master and 
  • Expert
The first and second don't really appear to be practitioners.  More the people we do software engineering or project management to.  You'll need to go read the article to get the descriptions. The article itself is quite funny as well as insightful and you should thanks Shim for highlighting it.

Okay, read it now. Bye, and see you next post.

Knowledge Externalization: BA Friend or Foe?

Library of knowledgephoto © 2009 Shironeko Euro | more info (via: Wylio) One of the things that I'm known for around the office is using technology in what most people see as 'novel' ways. I was one of the first people to cart around his laptop to every meeting, taking use of the wireless access in conference rooms to open up reference documents or take notes. Now, my laptop gathers dust on my desk and my iPad is my constant companion in meetings. Using Simplenote and Dropbox, I can access and edit all of my documents from my entire career, with just a few finger-taps.

Let me level with you, I hate memorization. Always have and always will. It just seems such a waste of time to me. If I know how to find the information in a very rapid manner, why should I bother to memorize it? It doesn't help that, when you look at my ratings on IQ tests, that memorization is the absolute lowest score of all categories on the tests. I'm bad at it, so I've found ways to compensate for the thing I'm not really all that good at.

It is with this background that brought me to a TechCrunch article about the 'dangers' of externalizing knowledge. Truthfully, I do get the author's point, that if we completely devalue retaining any information, then we will have a lot of problems learning anything new. I just feel that he takes the point to the level of absurdity.
We’re looking up more things, more often, and not because we’re more curious. It’s because we can’t be bothered to retain even the data that matter to us. The GPS in cars is an advance party of this trend: every couple months we hear of some driver who has followed the GPS to the bottom of a lake, or used a highway as a walking path because it was labeled as such on their phone’s map.
Let me contrast that quote with an anecdote from my mother, a 6th grade english teacher on the usefulness of vocabulary memorization versus learning to use a dictionary. She disliked the amount of class time she was required to spend on vocabulary quizzes. To her, if she taught a child the proper way to use a dictionary, then they could deduce the spelling of a word closely enough to look it up and confirm the exact spelling. If she had stopped there in her argument, then the TechCrunch author's points might have been valid, but my mother took it one step further. After a child looked up the same word half a dozen times in the dictionary, they would no longer need to look it up because the memorization would happen. Why would this occur? Simple, the process of looking up the word repeatedly would cause the word to become so familiar that the process of repeatedly looking up the word would become a disincentive to the child.

In simple terms, the bother of looking up that same word again and again would become so great that the word would imprint itself in the mind, just so the child wouldn't have to pick up the dictionary again.

To me, externalization of knowledge is just another way to learn, one that values process and creativity over rote memorization. We learn the information both ways, but using an external repository ensures that we only learn the most important things and allows us to keep our minds clear for what I consider more important tasks: knowledge synthesis and creative thinking. I look up knowledge and spend my time trying to put together the big picture instead of trying to commit it all to memory, then synthesizing it.

For Business Analysts, I think this presents some interesting implications. One of the reasons that I feel I've been successful at business analysis, is that I've developed the skills needed to think like my stakeholders. Given a short amount of exposure to a business process, I can generally determine the needs, fears, wants and desires of the people who carry out or manage that process. I do this not by memorizing every rule, step or decision point in the process, but by immersing myself in the thought patterns of the people in those roles.

When I need to look up specific rules to cite them in a document or presentation, I know where to go find them, either within the minds of my stakeholders or within the policy and procedure documents. After looking up the same information a couple times, I no longer need to look it up as the memorization has taken care of itself through long exposure.

This leaves me time to think creatively about the problems my stakeholders face. Yes, I need that detailed knowledge to verify that the creative solutions I've come up with will meet their needs in the way I believe it will. I open up those detailed documents or facilitate a review session in order to confirm my insights. I use those external knowledge source to their fullest until I have absorbed the information I need, without taking up valuable time to memorize the information in its entirety.

So what about you? Do you externalize your knowledge or do you memorize first? Despite what I've written here, I don't think you are wrong if you memorize first, but it is a strategy that has its drawbacks. I'm sure you can find some drawbacks in my methods as well. Point them out down in the comments.

4 January 2011

Thomas Edison and Innovation

The long-lasting light bulb. The phonograph. The motion picture camera. When we think of big successes in innovation, Thomas Edison's name can't help but make the list. The man holds 1,093 patents, making him one of the most prolific inventors in the history of the world.

RobotDoll2-Post.jpgBut not all was rosy for Mr. Edison. Despite that large list of successes, there is an even larger list of failures, some of which are quite interesting as they teach some really good lessons. Edison's doll with a phonograph inside it, made me realize exactly how far ahead of his time he was. Had he developed this in the 1980s, when Teddy Ruxpin was all the rage, instead of the 1890s, he might have had a winner on his hands. But in being so far ahead of his time, he ended up more of a loser on this one than a winner.

So what lessons can we draw from this failure of Mr. Edison? First, just because you can build it, doesn't mean you should. Technology is great, but sometimes something more simple, even just a better manual process, might be more appropriate.

Second, don't let failure stop you in your tracks. Edison's failure with the doll happened 40 years prior to his death. He didn't let this one stop him; he was inventing up until just months prior to his death. Learn from failure and make better decisions next time.

Third, learn timing. You don't always have to be first, but you do need to be timely. Being there with the right idea or product at the right time is better than being early or late. There wasn't much Edison could do to wait 90 years for his doll to be viable in the marketplace, but there is nothing to say he couldn't have created the genesis for the idea and then left that for his heirs to fulfill when the necessary technology had reached a cost and size ratio that was likely to make such a doll a success.

Those are the lessons I got from this article. What did you pick up from it?

2 January 2011

Wikipedia: Requirements Analysis

Hi Readers,  The Wikipedia article on Requirements Analysis needs your help.  I read it and thought that it exhibited a lot of what is troubling the practice of requirements management in general.  Take a look yourself.

(I should also highlight that I got to the Requirements Analysis page when I was actually searching for the Requirements Engineering page.  They have been merged in an awkward way, with an assumption that the two concepts are the same.)

I have added the below comment to the discussion page of the Requirements Analysis page.  What do you think?  Either offer your comments below, or add your weight to the actual discussion on Wikipedia.

Time for a rewrite?

Firstly I'd like to acknowledge the fine work done by authors and contributors to get this article to it's current state. I think it's sufficient to give a new requirements engineer/analysts insight into some key issues.

However, when it comes down to it this article needs some solid rework. Apart from the conflation between requirements engineering and analysis there are a number of issues. In many ways this article exhibits the characteristics of poor requirements cited by academics and industry observers and is the anti-thesis of what a good requirements analysis description should be.

I don't want to jump in half-cocked so I want to pose some questions to start, get a bit of discussion and then look to either some major reshaping of the content or developing a framework for continuous small improvements.

  • What is requirements analysis?
    • Is it a subset of a requirements engineering process?
    • Does a new Requirements Engineering page need to be (re) created?
    • Is Requirements Analysis a sub-system or sub-process of any higher level models? 
      • For example; I think it's an activity in the Business Analysts Body of Knowledge AND a process step in the Requirements Engineering (and Software engineering) paradigms.
  • Who performs Requirements Analysis?
    • Examples I can think of; Business Analysts, Software engineers, Product Managers, and Process Managers. No doubt there are more.
  • Why is Requirements Analysis performed?
    • There is a cost for doing this work. What's the benefit? 
    • Is there any variation in value and importance based upon who is doing the work? 
      • For example a software engineer is probably approaching an issue with a different focus to a process manager.
    • What is the contribution of good requirements analysis to business and project outcomes?
  • Where is requirements analysis performed?
    • Some examples that spring to mind include; Software houses, Product development labs, "enterprises" (i.e. large companies and government dept's.) 
    • Got More?
  • How is requirements analysis performed?
    • There are so many approaches that this article should probably only refer to schools of thought. 
    • I guess the argument around software engineering could inform this. I don't know enough to break this down into a manageable list.
    • Are there any universal best practices? (I think so.)
    • Are there any industry controversies around approaches to Requirements Analysis?
      • E.g. Degree of forward planning needed, SSADM and Agile, System versus Business requirements, and so on. There is a pretty long list of opportunity for this section.
  • Industry information
    • Annual conferences
    • Requirements analysis (and engineering) journals
    • Industry bodies and reference guides

Anything else?  What ideas do you have?

1 January 2011

2011: R is for Requirements

Let me share with you my personal goal for this year on Better Projects.  I want to focus on exploring requirements management and the world of the BA in more detail.  I want to dig into the history of the practice and discover better ways of doing things.  I want to put together a more complete model in my head (and on this blog) about the who, what, where and so on of requirements management.

I want to do this because it's interesting.  And because it's an opportunity for me to learn and grow professionally.  And hopefully because it's of interest to you.

Thanks for reading, and I hope you have a great year.