30 September 2011

Business Analyst Metrics


A few days ago I asked the question; what sort of metrics can help analysts learn about their effectiveness and improve?

Of course there are disclaimers around metrics;  Don't let metrics drive unthinking behaviour.  Use metrics as a tool to improve.  It's probably wise to throw metrics away if you aren't using them actively to develop and test hypotheses.  Managers shouldn't drive the metrics, the workers should develop and own them because it is the workers who need to discover better ways of working.

Anyway, in my contracting, consulting and now permanent roles I have never seen a good set of BA metrics in place and being used, although there are a number of useful things out there.  So in the interest of stimulating curiosity and experimentation here is a list for you with some ideas on how they might be useful;

  • Measure % of specs that get peer reviewed by another analysts so that you can tell whether peer review is being systematically applied.
    • This is useful if peer review is an opportunity to share knowledge in BA practices and methods or in local business or technology subject matter from the experienced to the inexperienced. People say that peer review of specs also improves quality, but I think a better way of getting peer review is from a customer, developer or QA person, as you'll get perspectives tat matter more. In my view peer review of requirements specifications is really about knowledge transfer, that managing quality in.
  • Measure elapse time on sign-off so that you understand the priority and confidence stakeholders have in the work of requirements analysts.
    • If there is a short elapse time your stakeholders have come on the journey, are engaged and trust the BA's contributions. If the elapse time is long then people are putting off opening the document for a number of reasons including lack of engagement, fear of not being able to handle and process the content, lack of time, a sense of powerlessness, etc.  If any of these things are happening the BA is not doing their job sufficiently.
  • Measure bugs reported in UAT so that you know how aligned you are to your client's expectations
    • UAT should not be capturing technical bugs, as they should be captured prior to acceptance testing.  Acceptance is really about whether your set of features and capabilities add up to what the client needs or expects.  While you may have some technical defects in a low maturity team most defects here are failures of the requirements management process; "That's not what I thought I was getting."
  • Average Cycle time from start to stages and the end of the project to help understand and improve your estimates and to help standardise the size of requirements
    • All that lean and Kanban stuff you hear about is true.  Understand the system and the flow of work and you can improve it.  You can work this out simply by counting requirements and checking the project's start and end dates, and drill into detail from there.
  • Effort per requirement
    • Similar to elapse time this helps you understand the cost of requirements and make better choices about prioritising and including certain classes of requirements
  • Re-use of requirements
    • Count how often you are reusing previous requirements assets to determine whether they are of good enough quality to re-use, to see how well you are recognising patterns and to help simplify the enterprise's application architecture
Most of these are do-able right now, perhaps with the exception of the last one where you'd have to have some sort of data about reuse tracked.  

To check re-use rates a card carrying agile team might be able to check requirements re-use by how dog eared and notated a card is.  If you use an RM tool you might be able to get data based on relationships with test cases.  If you are using MS Word and Visio you might have to apply some cunning.

What do you people do?  What do you do with the data when you collect it?


What's going on, are our methods changing?

At work people are asking "Are we going to use agile processes now?" Do we have to do these stand ups? What's going on, are our methods changing?

I don't have any particular view on process or methods that I want to impose except; be professional and don't do stupid things on purpose.

For me that encapsulates all the stuff on process - around delivering quality work, and trying to weed out bad bureaucracy and practices.  People can work out their own details.

But there is something more. We are all part of a community. We need to talk and share with each other and work as a team. 
Learning and sharing knowledge is also core to being en effective organisation. How can we make this fundamental to what we do and how we operate?

It's up to all of us to work this out together.

29 September 2011

Jobs on Generalists

One of the things I look for when hiring a business analyst is a good grounding in liberal arts. That might seem odd, given that business analysis regularly lives at the intersection of business and technology. Yes, those skills are vitally important and it is difficult, but not impossible, to be a good BA and not have both. But a great BA is something else entirely.

You know how to put together the most perfect requirements document? An administrative assistant could probably fill out the template if given the words.

You know how to interview people to find out their problems? Yeah, a psychologist gets paid to do that as well.

Can you follow someone around the office, watch what they do and report all that back to a developer? Its called a video camera.

We prize hard skills in a BA. Its difficult, if not impossible, to do the job with at least some rudimentary understanding of these skills. Some of them seem to the outsider to be nothing more than basic problem solving skills, and when practiced at the entry level, really are not much more than just that. As we progress in our career, we recognize that to really be great at what we do, we have to move beyond just problem solving.

That's where it pays to be a generalist. That's why this quote resonates with me:

It comes down to trying to expose yourself to the best things that humans have done and then try to bring those things in to what you’re doing. Picasso had a saying: good artists copy, great artists steal. And we have always been shameless about stealing great ideas, and I think part of what made the Macintosh great was that the people working on it were musicians and poets and artists and zoologists and historians who also happened to be the best computer scientists in the world.
—Triumph of the Nerds, PBS, June 1996

One of the best ways to become great at being a BA is to shamelessly steal from everyone. The more knowledge you have packed away for a rainy day, the more likely you are to have the necessary nugget of information that is the only solution to the given problem.

So that's the secret sauce, a wide and varied experience. The more you travel, the more you read, the more you study, the more you experience, the more likely you are to have the foundation for a killer business analyst. Open your mind, broaden your horizons and reach beyond your grasp.

26 September 2011

NoSQL and the impact for System Analysts

I love Ars Technica. Its a fabulous site. For what is the first time I can remember, they actually used the words 'business analysts' in a post, so I was naturally drawn to this post about Teradata combining SQL and NoSQL databases into a single product.

In all fairness, the article really isn't about business analysis, but it does bring up some interesting points for those of us who are business analysts that stray over into the system analyst realm. I've been curious about NoSQL in the past and done a small bit of reading about Hadoop and Big Table in the past, but really didn't know a lot about how either system really works. SQL is something I get, and while I am by no means up to the caliber of a qualified DBA, I can write some mean select statements.

My day job captures a lot of 'little' distributed transactions. Our back-end database servers aggregate that data and I am on occasion called upon to do some research, either to find a problem or to figure out what to do for the future. To do this research, I always use SQL. I realized that 'NoSQL' systems obviously didn't use SQL to find data, but I had no idea what they used instead.

This is why the Ars article was so enlightening to me... there really isn't an alternative to SQL, except code.

That's disheartening to me. Yes, these large data structures make it possible to store a lot of data in a lot of places, but it clearly is a step backwards in allowing anyone who is not a developer to freely access that data. These products require me to either learn a programming language or use programming-like syntax to find the data I need. There's a reason I'm not a programmer and requiring a programmer to give up time to help me find information is a really terrible option.

The Teradata solution, while a bit light on the documentation details, seems to provide a translation layer that either converts SQL into a map reduce language or vice versa. I expect that there is likely some performance degradation in this type of translation, but given that business analysts are unlikely to be performing a large number of searches repeatedly and overlapping on a single data set, I expect that the translation would be fairly minimal.

When companies come out with tools like this that allow developers to maximize the potential of an application but enable analysts to still perform their duties, I can't help but applaud. While I don't know if I will ever have the opportunity to work with this product, I like that business analysts are considered to be important enough to organizations to have tools created that enable them to be more effective in their work.

21 September 2011

Pete Cohen; Analyst and blogger


Yesterday Pete Cohen published his first post at Better Projects.  The post was on improving risk management techniques.  It reminded me of one of my earlier series Risk Management 101.  We hope to see more of his posting here, and I am sure we will.

Pete is an analyst and consultant in Melbourne. He is an interesting guy and is very focused on learning and practising skills in a pursuit of excellence and mastery.

Pete has already taken steps to amplify his learning by signing onto the BA Mentor program run by Alex, Doug and others.  You can listen to an interview about his mentoring experience at Alex's website here.

Welcome to the blogging team Pete.

Measuring what analysts do

Let me start by saying this: You can't manage by metrics.

But metrics are important tools that help you understand how you are performing today.  Measuring things can help you understand how you are performing against past performance, against expectations or competitors.  They can help you find defects and bottlenecks.  They can also help you understand the system you are operating in better.

And you should measure different things at different times.  My philosophy behind measurements is that you are collecting data so you can perform experiments to test improvement ideas.  Once an idea has been developed and tested, it is time to change the measures.

So, what metrics can we apply to the activities that business analysts do?  What background data can you collect that helps you develop hypotheses and test them?

I have a couple of ideas that might be useful at once time or another.  I'll post them in a few days.  In the meantime, do you have any suggestions?

20 September 2011

An Approach For Wording Risks

Capturing risk is something which we all do as part of the projects we work on (or at least should do).

The risk registers I have encountered vary greatly in terms of the language used and the level of detail they go into. Sometimes a risk is expressed as just a couple of words, which although may speak volumes to its author, don’t always give enough information to all relevant project stakeholders - for example, ‘content migration’ or ‘server load’ or ‘key resources unavailable’ are some risks I have seen recently documented. The ambiguous language can become a problem when it comes time to rate the risk and to devise mitigation strategies.

I was recently introduced to a simple formula for wording risks, which I have found very handy in overcoming the shortcomings outlined above. It goes like this:

There is a risk that…
Because…
Which could result in…

The first part (‘There is a risk that’) describes what the thing is that could happen. ‘Server load’ doesn’t work in that sentence, but ‘web server capacity could be exceeded on launch day’ does. Note that it is specific in nature.

The second part (‘Because’) tells the reader why it could happen. This is the essential part for rating the probability of the risk, and also when thinking of ways to avoid or manage the risk. To run with the server load example ‘There is a risk that web server capacity could be exceeded on launch day because news of our product might go viral’.

The third part (‘Which could result in’) outlines what the consequence could be if that risk materialises to become an issue. This is important for rating the potential impact of the risk, and also for devising the strategies to deal with it. So, to cap off our example:

There is a risk that web server capacity could be exceeded on launch day
Because news of our product might go viral
Which could result in people not being able to access the website or buy the product online due to browser timeouts.

From there, our project stakeholders can consider the likelihood of the product going viral on launch day (certainly not a bad problem to have!), and what the impact of new customers not being able to access the website on such an important day would have on the business. Then specific strategies to deal with that risk can be devised, and the cost of having them in place (or not) can be weighed up.

19 September 2011

How a BA is like a print newspaper

One of my favorite bloggers right now is Timothy B. Lee. Several months ago (yes, I'm working through my backlog of articles to write about) was about how the online news business had caused major disruption in the business model of traditional news media. If you've watched any media in the last decade or so, you can't help but see this as true. 10 years ago, I had already started consuming a large portion of my fairly small news consumption online. Its been 6 years since I disconnected my cable TV service (but kept the cable internet service) and now, the entirety of my small news consumption is done online.

What makes me interested in this, despite it being about news coverage which I am almost completely uninterested in, is the way in which I think it parallels the work I do as a BA. That might seem like quite a stretch on the surface, but hang with me a minute and think about my logic. First, lets look at a couple quotes from Lee to see where I'm going with this:
It’s only a matter of time before somebody figures out how to apply the low-costs tools of the web to high-value reporting. And the nimble, collaborative nature of the web means that successful models will be copied rapidly... But that was a misunderstanding of the economics of disruptive technologies. They always start at the low end of the market, but they rarely stay there.
One of the things (but by no means the only thing) that BAs do really well is to help our business users relate to technology and how it can help our businesses thrive. In a way, our jobs are dependent upon technology being a 'black box' to people forever. When our customers no longer need us to explain technology or how technology is created to them, then we'll not be in the jobs we've been in for years now.

Don't get me wrong, I think this will be a long time coming, probably 2-3 generations at the least, but I believe it will come. Lee gives us the reason in that quote above; disruptive technologies always start at the low end of the market.

The last decade has seen a large amount of work done on helping the consumer become more acquainted with and accepting of technology in their everyday lives. In some areas, cell phones, music players, the change has been striking. The mp3 player as it existed a decade ago held very few songs and did little else than play music. Now they're so large you can hold not only your music collection, but movies, pictures and even create digital content on a device that fits in your pocket with room to spare.

These consumer devices are the low end of the market. Remember the first time you had to show someone how to use an mp3 player? Now look at an iPod touch and you'll realize that one of the things that is great about the progress of the last decade is that we don't have to show someone how to use the device (at least for the common things).

Disruption has been tracking in the low end of the market for sometime; now its starting to move up the chain. For this, look at all the project management apps that are eating into Microsoft Project's territory. Tools like BaseCamp allow less knowledgeable PMs a tool that, while it may not have all the bells and whistles of Project, can help them successfully manage a project without needing to attend weeks worth of classes first.

But so far, we're not really into the territory of what BAs do with technology, namely when it comes to enterprise applications. While the trend isn't quite yet as encroaching on us as it is the lower segments of the market, it is coming up fast.

I used to work with ERP and CRM applications when I started out almost a decade ago. Those apps I worked with then look largely exactly the same today. Sure, engineers added some backend functionality, updated for modern browsers and tacked on a few modules, but the apps themselves are largely unchanged. What is different are the applications that are their main competition. 10 years ago the only competition these applications had were other enterprise applications. Today, anyone with a Kickstarter account and a good enough idea can take the large, incumbents on head to head.

The thing is, I don't have a problem with any of this change. If my role as a BA disappears in 30-40 years, even if I am long retired, I'm good with that, so long as whatever replaces it is sufficiently better. If we get to the point where children born around the time of my 80th birthday can 'get' technology as intuitively as kids born 600 years ago 'got' farming, that's great.

In the end, its the skills of a BA that will live on, even if the role itself is eventually discarded. Technological change happens, no matter if we accept those changes or not. If we don't, someone else will and they will eat our lunch. In our role, we are uniquely equipped to not just deal with change, but to cause it. As long as we continue to do that, our skills will always be needed.

15 September 2011

The Cult of Done Manifseto

I love finishing something. Being able to check that item off my list is an awesome feeling. I'm a huge fan of the Inbox Zero concept because of this. This is why items like the Cult of Done Manifesto makes me so happy. For those who don't want to click the link (although I suggest you do for the cool poster), here is the short text of the manifesto:
  1. There are three states of being. Not knowing, action and completion.
  2. Accept that everything is a draft. It helps to get it done.
  3. There is no editing stage.
  4. Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it.
  5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
  6. The point of being done is not to finish but to get other things done.
  7. Once you're done you can throw it away.
  8. Laugh at perfection. It's boring and keeps you from being done.
  9. People without dirty hands are wrong. Doing something makes you right.
  10. Failure counts as done. So do mistakes.
  11. Destruction is a variant of done.
  12. If you have an idea and publish it on the internet, that counts as a ghost of done.
  13. Done is the engine of more.
Point #2 is by far my favorite of this chart. Its freeing. I know my PM friends get frustrated with me when I say a task is 'pretty much done'. This isn't a situation where I'm trying to get them off my back about the status of a task, but a way of saying that its as done as I know how to make it. It is an acceptance of the large amount of ambiguity in life.

Point #4 just makes me laugh. 

Point #10 is so true. That doesn't mean that you don't have a new task that looks exactly like the one you just failed at, this time to do it correctly, but it does mean the original task is done.

Point #12 is pretty much this entire blog. :-D

14 September 2011

Think

A great deck about thinking. make sure you watch the video mid way through.

13 September 2011

Lunchtime talks: Intro to Retrospectives

Over the last few weeks I have been doing Tuesday lunchtime 'lecture-style' talks to the local software dev teams. The first week was "agile 101" with a run through scrum. The second week was a description of Kanban's visualise the workflow and limit work in progress ideas. This week is going to be retrospectives. 

Rather than do too much preparation I have been looking up decks on Slideshare and re-using existing content. Today's retrospective slide deck is care of Esther Derby.

12 September 2011

BLS Outlook for BA and PMs

One of the bloggers I follow on Twitter, who has nothing to do with our chosen field of work, pointed me towards the website for the US Bureau of Labor and Statistics. While there, I spent some time reviewing the job prospects and salary ranges for BAs and PMs (which I am going to assume fit into the Computer and Information Systems Manager category).

Some interesting quotes and takeaways, first from the BA page:
  • Employment is expected to increase much faster than average.
  • Excellent job prospects are expected as organizations continue to adopt increasingly sophisticated technologies.
  • Employers generally prefer applicants who have at least a bachelor's degree; relevant work experience also is very important.
Its good to be a BA in today's world.
 analysts are increasingly working with databases, object-oriented programming languages, client–server applications, and multimedia and Internet technology.
It seems as if the BLS feels BA jobs are becoming more technical instead of less.
Computer systems analysts held about 532,200 jobs in 2008. Although they are employed in many industries, 24 percent of these workers were in the computer systems design and related services industry. Computer systems analysts also were employed by governments; insurance companies; financial institutions; and business management firms. About 30,300 computer systems analysts were self-employed in 2008.
Those job numbers are obviously for the US, so your mileage may vary in your country. Still, that means there are a lot of BAs out there in the world. I would bet there are even more doing the work, but just don't have the title.

Lastly, some salary info:
Median annual wages of wage and salary computer systems analysts were $75,500 in May 2008. The middle 50 percent earned between $58,460 and $95,810 a year. The lowest 10 percent earned less than $45,390, and the highest 10 percent earned more than $118,440. 
We won't, generally, get rich from this job, but will do pretty well for ourselves. Not bad.

Now lets look at some points for PMs.
  • Employment is expected to grow faster than the average for all occupations.
  • A bachelor's degree in a computer-related field usually is required for management positions, although employers often prefer a graduate degree, especially an MBA with technology as a core component.
  • Many managers possess advanced technical knowledge gained from working in a computer occupation.
  • Job prospects should be excellent.
As with the BAs, PM roles seem to have a good future to them. But there is a bigger downside for PMs than BAs.
Long hours are common, and some may have to work evenings and weekends to meet deadlines or solve unexpected problems; in 2008, about 25 percent worked more than 50 hours per week.
The number of hours worked for PMs seems to be higher than for BAs. 
Computer and information systems managers held about 293,000 jobs in 2008. About 16 percent worked in the computer systems design and related services industry. 
When compared to BAs, there are fewer in the management field, but those jobs seem to be spread out over a wider set of industries.
Median annual wages of these managers in May 2008 were $112,210. The middle 50 percent earned between $88,240 and $141,890.
In return for those longer hours and additional responsibility, it seems that PMs do command a higher salary.

There was one thing I noticed that were not discussed in either of these profiles. In the education section, there really wasn't any mention of professional certifications (CBAP and PMP). While there was a significant amount of discussion of college, graduate and technical degrees, the role of certifications was largely ignored. With the popularity of the PMP and the growing popularity of the CBAP, this did surprise me.

What do you think about these articles and what they say about our chosen professions?

10 September 2011

Agile mashups

This idea has been with me for a while. The various agile methods are all fine but seem to lead into this common mix of XP, Scrum and Kanban techniques, with some additional Crystal methods thrown in for good measure. Rachel Davies published a nice deck on the topic. What does your agile team do?

7 September 2011

6 September 2011

We are losing our listening

Great tips here, but best quote is this:
Many people take refuge in headphones, but they turn big public spaces like this, shared soundscapes, into millions of tiny little personal sound bubbles. In this situation, no one is listening to anyone.



2 September 2011

Unlocking Project Achievements

As I've talked about in the past, I'm a pretty big fan of social media and especially the ways it can be used as a driver for projects. One of the areas of social media that has always seemed a bit silly and frivolous is the concept of 'badges'. Foursquare was my first experience with them, but now it seems every social media site (except the juggernaught of Facebook) has them. Even non-social sites, like Google News, has them.

But what about for those of us who work on projects? Should we get badges? Over at the Red Earth QA SIG blog, they seem to think it might not be a bad idea. The post lists some badges that QA analysts could earn, some of which are pretty funny...
Dead Parrot - You have an extremely difficult time convincing the developer that their ‘fix’ does not, in fact, fix the issue. After several hours of showing all the ways that the issue still exists, you are offered a slug.Jar Jar - Every bug you submit requires clarification. For this, you are made team lead.
I've been kicking around ideas for this post for a while, trying to find some awesome badges for BAs and PMs, but I'll be honest, my funny-bone doesn't work well with lists (or at all, if you believe most people). So here's what I've come up with. Use the comments and add your own!

General Badges

  • Newbie = Congratulations! You just landed your first project. Here's a helmet and a yo-yo. Go forth and conquer!
  • Old Hand = 25 projects under your belt. Most people never make it here, but you're a survivor.
  • Grey-beard = You're the person who makes Old Hands quiver in fear. With well over 50 projects down and still not retired, you serve as a warning to others what can happen when you've been doing this way too long.
  • Wide-load = Working more than 5 projects at any given time? That's an average of 8 hours per week or less devoted to any single project. Do you feel that anything is being neglected (besides your personal life)?
  • Extra-wide BC = Your business card width had to be specially sized due to the number of titles you included after your name.
  • Social Butterfly = You've checked in at 5 or more industry events in the last month.
  • JetSetter = You've traveled for business at least 5 times this month.
  • Home Office = You performed at least 1 hour of work from home every night of the week.
  • Drop the iPhone! = You answer emails between the hours of midnight and 4am.
  • Name Dropper = "This one time, when I worked at XXXX company, we did..." is heard from  your mouth at least 3 times in the same week.
  • Dirty Harry = You're a hired gun, brought in for your specific expertise... in killing projects.
Business Analyst Badges
  • Smarty-Pants = You have your CBAP or CCBA.
  • Verbose = Your requirements document is 5 pages or more in length to change the label on a field.
  • Buffy, the Requirements Slayer = Your 'stake'holder analysis charts are so comprehensive they include the cell phone #s of the company's janitorial staff.
  • Scope Creep = Can only be awarded to you by a PM. Occurs when you slip in additional requirements on 2 of the last 3 projects after sign-off has occurred.
  • Cartographer = You've created flowcharts for everything, including one on how to decide if you need to go to the bathroom.

Project Manager Badges
  • 4-Eyes = You have your PMP, CAPM, PgMP, PMI-SP or PMI-RMP.
  • Under Pressure = You are the king of schedule compression. At least 50% of your resources on a given project have tasks on the critical path.
  • Braaaaaains = You've been the PM on this same project for 5 iterations. Its a zombie. It won't die, it keeps coming back every time you think you've killed it even if you removed its head.