Search This Blog

30 July 2010

Heavy Thinking

I dislike giving out immediate answers when someone comes with me to help them solve a difficult problem. Sure, I can give you a quick answer which may or may not be the best possible answer, and possibly may not even be a good answer, but difficult problems deserve plenty of time and numerous thoughts before they should be solved.

Albert Einstein's general relativity was developed from 1907 to 1915, not in the blink of an eye. Yes, it is unlikely that any of us will ever encounter any problem which would require thinking of that deep and sustained nature, but that does not mean we will not combat and conquer only easily solved problems.

When I need to do my heavy thinking, I go to sleep. More precisely, I lay down in bed and let my mind take a meandering path through the problem space. I uncouple the 'obvious' linkages within the problem and see what happens when I couple items which would normally make an unimaginable combination. Its during these times of free association that I regularly hit upon a solution to my most difficult issues.

When I read a blog post by Paul Graham about The Top Idea in Your Mind, I instantly understood where he was going in reference to his morning shower. His best thinking is done there, just as mine is done in the minutes (and sometimes hours) between laying down and falling asleep.

As a child, I was raised in a Baptist church. One of my youth ministers claimed that reading the Bible as the first act of the day was vitally important for everyone and is something he wanted all the youth to do every day. As a means of 'encouragement', he once set up a phone tree so that the youth such as myself who were NOT morning people would be called every 2 minutes by the youth who were morning people to remind us to get out of bed.

I bring up that story as a way to show that sometimes even the best of intentions cannot produce quality results. Just like I could never do quality thinking in the morning like Paul Graham does, it is unlikely that he could ever do his deep thinking as he fell asleep in bed.

To give a fair assessment to problems my stakeholders bring, I generally ask them to let me sleep on it first so I can give them the best answer possible. My stakeholders know this about me and I believe they respect me for it, mostly because they keep coming to me for answers.

What about you? Where and when do you do your best thinking?

28 July 2010

Project Theme Songs

Hi, I am your completely random post for the week.

Two weekends ago, I was introduced to a new musical artist and became immediately enthralled by his work. I was a music major for my first two years in college, so me becoming infatuated with an album or artist isn't really all that uncommon.

What is interesting about this artist is that the mood of the music did not in any way fit my life at this moment. Usually I find that new music which really resonates in some way draws a connection to the experiences and emotions found in my life at the current time. It wasn't until an event at my office several days later that I found out why this music would end up being so important to me. In fact, I don't know that I'll ever be able to listen to this artist again without thinking of this situation.

This is not the first time for this to happen to me, either. Back in September 2005, I was helping to support a large rollout in Europe. I spent essentially the entire month in France, with the last week of that trip as the only person from the US. By that point, I had spent months of my life shuttling back and forth between the US corporate headquarters and the EMEA headquarters, so while I was very familiar with my location, it ended up being one of the most lonely times of all my nine trips.

At that same time, Green Day's "Wake me up when September Ends" song from their American Idiot album was extremely popular. Prior to leaving on that trip, a friend had given me a gift of that album. The last week of September 2005 ended up being forever matched with that album. More specifically with a little Irish pub in downtown Orleans, France, where I sat alone at a small corner bar, wondering why I was spending my life on a project that had abandoned me in a foreign country. It was this event which sparked my eventual departure from that project and that company. This song and album are inalterably linked in my mind with loneliness and separation due to a specific project.

A happier event, months before that lonely September 2005 evening, a different song became linked with that same project. It was a much happier time, with the project in an earlier time. Our project manager had declared 'Funk Fridays' and would play all types of Funk music in his office on that day of the week. Normally he had headphones on to partake in his funkiness, but one particular Friday he failed to properly plug in his headset and was unaware that the loud music was coming from the laptop speakers and not his headphones. As the Commodores 'Brick House' blared out of his office door, most of the team gathered to watch as he jumped, jived and whaled from his desk chair. Only after a few minutes of squelched laughter in the hallway did he notice his audience. He was mildly embarrassed over the event, but it became a running gag to find out what he was listening to every Friday.

So what about you? What memories do you have of specific music being tied to specific projects?

27 July 2010

BA World Melbourne 2010

I went to the Business Analyst World Conference in Melbourne on the 19th and 20th of July. Like last year it was a great event.  On day 1 I spent the whole day in one room (introducing speakers.) and got to listen to three very different stories.

Matthew Coppola from Perth training outfit Paramount Training gave a talk on Understanding Strategic Planning.

It’s always useful advice to go back to basics: Where do you want to be? Do you understand your capability? Mathew’s talk gave a simple framework to drill into these two questions. (See a transcripts of the whole talk here.)

Something that struck me while listening to his talk is how odd the world is. So many of us profess to know this stuff, but when you get out into the pressure of deadlines and complicated personal relationships – how many of us stick to the agenda and define the problem sufficiently before getting into implementation mode.

The second talk I saw was by John MacLeod of IBM’s Rational team on Steps to Better Requirements Management. This was the basics of requirements management: Start with a technology neutral business requirement statement, evolve it into a solution constrained by a particular IT or system scope and finally resolve it into specific statements of functionality. And trace things from front to back to keep up with what is getting done and what isn’t.

The third talk was a case study of a project delivered in NSW police by Peter Stanford of Artefaction called Architecting change – from Here to Eternity, or Agile and Now. This talk centred around the problems of getting consensus on big decisions in large, complex and diffuse organizations. The guts of the answer seemed to be making the decisions frequent and small, and using prototypes wherever possible.

On Day 2 I filled in for Paul Culmsee who was unable to attend – and did an ‘intimate’ Q&A session for two tables of people who wanted to ask questions about implementing agile practices. Matt Hodgson and Peter Stanford also sat in answering questions. It was fun and the people there seemed to like the more interactive nature of a conversation over yet another lecture.

The rest of the session was really interesting with lots of good content and speakers. I was happy I went and recommend anyone in Australia (or NZ) to pop along to the Sydney event on the 17th and 18th of August.

26 July 2010

Nerds of a Feather/Central Coast NSW IT meet-up

A few weeks ago I mentioned some colleagues and I were going to start up a local IT meet-up.

We've committed to a date (17th August) and a location (Jack's Bar and Grill at Erina.)

So now there is a first event, a venue, a blog and even a twitter account (which eventually I'll get working so it posts from the blog.)

Now all we need is some people to come along.  

That's where we need YOUR help.


What can I say - I am a fan and you need to be as well. 

Go and sign up for the email udpates/facebook fandom/RSS or whatever is your flavour of keeping up.

Making Sensible Decisions

One of my early clients taught me how to not manage invoices in a company. This department's policy was that if any customer's submitted payment was more than $1 less than the amount on the original invoice, then the company would deposit the payment and reinvoice the customer for the remaining balance. Any payment short $1 or less had the remainder written off as bad debt and the check cashed. On the surface, this sounds like a fairly sound policy, but when you dig into it further, you realize there were a few problems.

First, this company processed thousands of invoices per year with values for as little as $30 up to invoices that were over $1M. During the three years of history I reviewed, the company had only written off maybe $50 in bad debt. Contrast that with the hundreds of invoices they sent back out to customers requesting the missing funds for invoices that were short more than $1. In the grand scheme of things, it seems as if they do a really good job of collecting on their debt. That's a good thing, right? Well, maybe.

Consider if you will that a customer who paid $29 for a $30 product received the product at what is essentially a 3.3% discount, but the customer who purchased enough product to total over $1M would receive a 'discount' of 0.0001%. Seems a bit odd when put in these terms.

But it doesn't stop there. When you dig further into the numbers, you see that the customer purchasing at $30 was essentially a one-time purchaser but the $1M customer purchased year after year after year. Doesn't it seem like a bad policy in terms of customer service to reject an invoice over $1.01 when the entire purchase is over $1M?

Now, you've reached this point and some of you are probably screaming and banging on your keyboards, "NO! You must have standards!!!" and I totally agree! I just call in to question if this particular standard was a good one or not.

Let me add one more statistic that was floating around our project team... the cost for the company to produce an invoice, mail it and process the return payment. Anyone want to guess what this cost was? It was $12. So, you've got a company that is willing to spend $12 to collect anything from $1 to $11.99 and lose money on the entire deal. When you total up all the costs to recoup the missing revenue, you find that the company was losing a significant amount of money just in managing their A/R to this level.

Eventually, we did convince the department to make a change, but it wasn't one we found satisfactory. Instead of $1 being the threshold, it became $5. It wasn't the change that we wanted, but in the end it was the most that the company was willing to budge on the policy. In a way, we had a win, but to this day I wonder if that policy is still in place and if so, how much money they continue to lose with bad policies.

What are some of the bad policies you've seen in your time? Let us know in the comments!

23 July 2010

Task Management on your Desktop

There was yet another good post out of my news reader today that brought to my attention the following image:

What I find so interesting about this is its simplicity as a task manager. There is no project plan here. There's no fancy program to tell you what to do and in what order. This is simply a desktop wallpaper where you drop documents you need to work on or other items of regular use. You don't need any elaborate filing system, you just find what needs to be done and do it.

My computers generally have very tidy desktops. I don't tend to be someone who lives with a lot of clutter, but on occasion, when I'm in the middle of several projects, such an organization strategy could help any individual task from getting lost amongst a noisy picture of some place I went on vacation years ago.

What about you? Besides pen and paper, your inbox or a project plan, what strategies do you use to manage your tasks?

21 July 2010

The Importance of Being a Failure

This video popped up in my news reader and I thought I would share it as an idea starter. When was the last time you failed? What lessons did you take away from that failure? What habits have you made since then that will keep you from failing in the same way again?

20 July 2010

BA World conference ends with a discussion on building organisational competency.

Here is my question; Does 'professionalisation' help or hinder the broader goals of the org?

Published with Blogger-droid v1.4.8

19 July 2010

Project Connoisseur

I love everything about wine. From the vineyard to the glass, the entire process simply fascinates me. I love talking about grape varieties, soil composition, weather patterns, oaked v/s steel, yeast, racking, bottling… the list just goes on and on. If you know anyone like me, or are yourself a fan of wine, you’ll know that there are lots of terms that are used by wine snobs that you’re not likely to hear anywhere else. There is a completely new vocabulary to learn if you want to be thought of as a wine connoisseur by your friends.

The same thing can be said for working on projects. We talk about project plans, predecessors and successors, KPIs, functional requirements, burn down charts, RACI matrix and requirements elicitation. These are terms that make sense to those of us who have worked on projects for years and allow us to communicate with other project people more effectively. This shared lexicon is a huge positive attribute when speaking with other people who know the language, but can be a huge detriment to people who do not know the language.

Lets use an absurd example to prove this point... If someone is dying of dehydration and stumbles into a wine party, what would you, the wine snob, do? Would you start to discuss the ways in which the skins were left long into the fermentation process in order to extract all the proper tannins? Or about how the grapes were allowed to desiccate and slightly mold on the vine, just enough so that their sugar content rose and their water content fell enough to make a perfect vintage?

No, you would not do this to a dehydrated person. You would give them water. Clean, pure, clear water. Wine is not refreshment; it is taste, flavor, texture and smell. Water is life (but wine is what makes it worth living!)

So why is it that when our stakeholders come to us with massive problems in their areas, why do we expect them to speak the language of projects? Our stakeholders don’t care about a project charter or gantt chart; they care about how their business is crumbling apart in their hands.

Its not that the language and processes of project land are not important; they are vitally important and I wish that everyone shared in my belief of their importance. I do my best, when my stakeholders are on solid ground and in no danger of drowning, to educate them in the how, what and why of project theory. Most of them are appreciative for the new knowledge and can quickly assimilate the lessons into their daily activities, but that is only when their first priority is not survival.

When next a stakeholder comes to you, I challenge us all to make sure that our response to their need is not to send them off with a project document template or a complaint about how you don’t have time for them right now. Spend five minutes, acknowledge their concerns, schedule them for a half hour meeting in the next few days where you can more properly focus on their need, lending them your expertise in helping to solve their problems. Even if you do nothing more than listen to them complain for the entire time, at the end you will have built a vast amount of good will that you can call upon in the future.

17 July 2010

Stop Starting and Start Finishing

Check out this SlideShare Presentation from Jason Yip of Sydney. (Care of his blog -

16 July 2010

Irrationality's Upside pt3: A 'Sensible' Bonus structure

In parts 1 and 2 of this series, I tossed out a few examples of current and bonus structures for BAs and PMs. Then I walked through the ways the current structures failed to drive results. Lastly, I looked at alternative options that, in my opinion, would be just as bad, if not worse, than the current methodology. Now lets turn our attention to what I think is a methodology which has the potential to drive better results.

To find out more about Dan Ariely, check out his website.

A Different Approach

We've rulled out measuring based on our customer's results and on trying to find the 'right' requirements for BAs, so what is left? If it were up to me, I'd do it in two ways, mostly depending upon how much revenue or customer satisfaction is directly attributable to your work or on how much cost you avoided by your efforts.

Let me return to m 'upsell' example from part 1, with numbers that are totally fictional for my organization. Lets say that I determine those upsells are bypassed 100,000 times per day and are only effective 50 times during any given business day. If those upsells produce $2 in extra revenue each, that's $100 per day. If I determine that each upsell takes approximately 5 extra seconds per customer call, then that's 500,000 seconds per day. Divide that up by an average 8 hour shift and you have approximately 17.36 hours at an average cost of $10/hour, making an expense of $173.60 per day. Say that of the $100 in revenue, you only make $15 in profit (before labor is removed) but have $173.60 in labor expense and those upsells start to look like a REALLY bad investment.

Not only could I actually save money by eliminating the upsells, but I save money by having a smaller code base and thus, less maintenance and documentation for developers and analysts. I'm sure there are other costs you could conceivable add in here (electricity, wear on servers, drive space, you get the idea) but the numbers make up the point.

Lets flip the scenario around and assume I figure out a way to make those upsells intelligent by looking at the customer's past order history, the items they're ordering now and the types of products other customers with the same demographic profile and then making smarter recommendations. If I up the number of upsells from 50 to 10,000, then the picture starts to look very different. Suddenly, I'm making $4,000 in profit (again before labor is removed) on $173.60 worth of employee time. When the order takers start to realize how potent of a weapon that upsell is in driving sales, they'll probably pay more attention and use it more, driving even more sales.

Still Not Perfect

Once again we're at a problem in our measurements because how do you know what is directly attributable to your performance and what is not. If you captured the requirement, but it was really the idea of a stakeholder, should you get credit for that? If the developer is the one that did the analysis to find the exact ratio between all the inputs, should all that revenue pot (or a percentage of it) be theirs?

This is where you have to factor in two more items: team and time. You really need to take a look at who was involved and their contribution to each saving or selling that made the difference. Second, you can't do one project, feature or phase, but have to measure over time. You get a slice of every addition you make and then each of those slices are averaged over a long horizon, and I'm talking years here not just a financial period.

By focusing on a team, and I don't mean that in the reporting structure definition of the word, you get lots of other side benefits like cohesion, group survivability, etc plus you remove the problem of needing precise measurements of who added what to each individual project. If someone fails to perform over time, the rest of the team will ensure that they either begin to contribute equally or that the underperformer leaves.

Measuring over time takes away the pressure of the financial cycle and puts the focus on long term health of the business. It also ensures that knowledge stays within a business and, if combined with an HR team that really understands how to recruit and retain top talent, allows for new, high-performing junior team members to gain an immediate foothold and be rewarded for their contributions.


So, am I dreaming here? Does this make sense? Do you have a better idea? Let me know in the comments!

15 July 2010

1.0 FTE is awesome

Dilbert has competition. Check out 1.0 FTE

14 July 2010

Irrationality's Upside pt2: Project Manager Bonus Structure

In part 1 of this series, I took a look at how the bonus structure for Business Analysts is not very efficient in driving better results. This time we'll look at the structure for Project Managers and an alternative method for structuring their bonus plan. Part 3 will discuss what I consider to be a 'better' way to structure bonus plans for all Project People.

If you want to know more about Dan Ariely, or his new book, check out some of the interviews with him over at Big Think.

Setting a Baseline

PMs, like BAs in the last post, usually find themselves receiving bonus payments based on whatever business unit happens to pay their salary. If you're part of IT, you follow whatever bonus structure they use. If you are part of a PMO and report directly up to the COO, then you'll find yourself following that structure. Wherever you are, it is often a place where you may find yourself having trouble making a direct contribution to the company bottom line.

I've seen PMs who are BOK-WONKS (a person who spends their time studying a Body of Knowledge instead of on more socially acceptable non-work activities) complain when anyone even mentions the 'Project Triangle' in a post. Its outdated and legacy theory that has been replaced by more accurate representations, you say. Quite true I say, but one thing you can't fault the triple constraint for is providing an easy to use and easy to understand relationship between multiple, competing factors. All of you BOK-WONKS out there hold on to the pitchforks for a moment because while my example here may be less precise, I'm going for a directional position and the triple constraint does a really good job at proving the point.

You've got Time, Scope and Budget. Failing to deliver on any of the three is a potential negative to the bottom line, even if it is only failing to correctly estimate the number of deferred hours needed to complete the project. But is this your fault? You don't control the requirements, so when the BA fails to correctly specify all the needs of the business, that is not your fault. If the developer runs over schedule by months because they are a code perfectionist and the resource manager won't agree to add more people to pull the schedule back in, your recourse to keep your bonus is limited.

While PMs are responsible for 'cracking the whip', if the whip-ee refuses to budge, you are not usually their resource manager so you're left with pushing issues up to a sponsor team to resolve. You report on the schedule and on the weekly burn rate, but other than suggesting ways in which people might perform multiple tasks at once or ways to slim costs by cutting scope or hiring cheaper inputs, you generally don't have the authority to actually implement any of these resolutions.

Now What?

Lets say that your management team decides to restructure your bonus calculation and ties it directly to your ability to predict and report on changes to that triple constraint. They want to see how accurately you can forecast and divine the winds of the project landscape.

You find out that 1/3 of your bonus is tied to each of the areas of the triple constraint. The closer you are to being on budget, the more of that 33.33% is yours. The same is true for schedule and scope. The problem here is similar to the problem with a BA, how do you measure each of these areas?

Lets take time... are we talking duration or effort? Both? If you end the project on time, but blow labor by 20% because you hired a bunch of contractors at the end of the project, should you really get the full bonus percentage for the time segment of the calculation? You may have hit your dates, but your effort is way out of proportion with what your resource managers felt the project would need. Similar problems would exist for quality (I shipped it on time and on budget, but it was unusable) and budget (throwing more bodies at it).

But there is a more fundamental error with this calculation, namely that being accurate in a measurement does not necessarily translate into better results. I had a PM trainer once tell a story of how, while he was PM for a project to build a palace for a Saudi prince, they came in on time, on budget and to the exact letter of the original plan. The prince, when being given a tour of the palace, stormed out within 5 minutes, refusing to talk to anyone about the building and refusing to take ownership of the property. After months of work, the project team finally got an audience with the prince.

They explained how they completed construction on time, how they were good stewards of his money and how they fulfilled the letter of the design. The prince's reply was simple, "But you put vinyl tile in my foyer. I'm a prince, what do I care about time, budget or scope if I am ashamed to show off my palace to the other princes because it looks cheap!"

The project team measured everything exactly, but failed in the most important ways, namely to meet the needs of their customer. Tying the bonus of a PM to their ability to accurately measure a project will not work because accurate measurements does not necessarily translate into correct results.

But Wait, There's More...

Part 3 of this series will arrive very soon, so watch for it in a couple days. Until then, amuse yourself in the comments by letting us know of other ways you've had your bonus calculated as a PM!

13 July 2010

0.1% defect rates

It's the end of one project and the beginning of a new one.  I thought I might share some stats from the last 18 months of my working life.

The most interesting one for me is 0.1% bug score.  

These are rough numbers but as of last week we had about 125K lines of code and 103 bugs from a system that has been in production for half of the 18 month project duration.  Another view of this number is about 0.7 bugs per developer month.  

The application was built with Dot.Net 3.5 and SQL with only a couple of interfaces to external systems.  Data defects resulting from data migrations from legacy systems were included in the bug count.  Visual Studio 2008 and TFS were the IDE and source control tools.

The things that gave us this number include a clear up front articulation that quality is our primary driver, a fanatical focus on testing at all stages of development by the team members, continuous integration and pushing the system into production as early as possible and relentless regression testing.  

We (maybe it was just me) had a thing going that we should never find a bug in UAT.  It was an aspirational goal, but it was almost true.

Of course there are some caveats.  
  • We never automated our testing so we may have missed some regression bugs
  • We may not have found all the bugs for outlier scenarios
  • We wrote UAT test cases with a view to testing business capability, not to test whether all outlier scenarios were caterred for continuously
But we have had it in production for 9 months.

Is 0.1% something to brag about?  Yes, it probably is.  Well done team.

Picture by PMSTW via CC @ Deviantart

12 July 2010

Nerds of a feather - Central Coast Techie meet-up

I live on the Central Coast of NSW Australia.

It's an area known more for beautiful parks and beaches that awesome IT teams and enterprise project management.  

I have had the same conversation three times in the last week revolving around the desire for a regular community event in the area for I.T. or consulting types to get together and share knowledge and experience.

This post is a call out to anyone in the area who is interested in a regular meet-up.  A couple of guys in my team and I will be hosting a monthly event starting August and if you are able to make it YOU are invited.

The first event will be Tuesday 17 August, at a location yet to be identified.

So - Central Coast IT workers - hear the call.

If you work at Belkin, Staffware/Tibco, Any of the large government offices (local, state and national), Sanitarium, Ashtons Scholastic, Masterfoods or at a small boutique web firm we'd love to hear from you.

Irrationality's Upside pt1: Business Analyst Bonuses

Dan Ariely'sThe Upside of Irrationality: The Unexpected Benefits of Defying Logic at Work and at Home (Hardcover)(2010)A few nights ago I started reading The Upside of Irrationality by Dan Ariely. If this sounds familiar, its because a few weeks ago I posted about his first book, Predictably Irrational. These are two fabulous books that unknowingly give you a great deal of insight into the economics of projects (and yes, there is an economics side to all projects, but don't think that means its boring!)

Chapter 1 focused on bonuses and their effect on our performance. The basic principle here, and I'm trying not to ruin anything for you, is that offering low (1 day of pay) or moderate (2 weeks worth of pay) bonuses result in relatively the same level of performance on cognitive tasks. Offering high levels of bonus (5 months worth of pay) results in significantly lower levels of performance. If you want to understand why this is, read the book. :) But this chapter got me thinking about how we measure and reward performance for project people. This post will focus on the business analyst side of the equation and I'll hit up project managers in the next post, then end the series with a post about how I believe bonuses should be paid out for people who spend most of their lives in ProjectLand (its similar to DisneyLand, with a cast of crazy characters, but far fewer bright colors).

Bonus Failures

If you're a BA like me and you get your quarterly or yearly bonus, you are often left scratching your head about how companies put together incentive plans. Right now, my bonus structure is tied to the operations function because the development team I work for creates software for the operations team. Sounds logical, right? Well, maybe.

Much of the bonus structure is about driving sales but when you look at the application we develop, very little of it actually focuses on driving extra sales. I can think of two different types of upsells that our order takers must walk through in order to save an order, but if you watch order takers in action, they most always blow right through the upsells. Many do ask the questions even if the system prompts are ignored, but it is rare when you look at the logs that they do anything to drive actual sales.

So what am I to do? Well, I focus on the smaller side of the bonus structure, on finding ways to cut costs. Even small percentage changes in labor and raw materials can make a big impact on the bonus structure, even if the change is smaller than an increase in sales.

But even then, my impact is still relatively small. I can build all the tools in the world, I can help the operations support area create the best training material for our software, but I can not force the field operations team to actually use it as designed. One of the things that has most amazed me in this job is the number of creative, and often counter-productive ways my users find around the controls we build.

Potential Alternatives

Despite the initial thought that aligning my job with operations is logical, it really is irrational. But how then should the company measure my performance if they don't tie it to operations outcomes? Well, I can think of a few ways:

My first thought was that you could tie my bonus to the accuracy of the requirements I elicit from stakeholders, but if I only elicit one requirement and it is correct, is that worthy of my entire bonus? If I elicit 1,000 and only one is right, but that one is worth more than triple the other 999 combined, do I not get any bonus?

But even if you found a correct formula, how do you even know what the 'right' requirement is? What is a 'right' requirement today may be completely wrong after it has been implemented, especially for projects that have a long timeline in industries where the business environment changes rapidly.

Even if you got the requirements 'right' by 'skating to where the puck will be', who measures if this is right? The first thought would be stakeholders, but they have enough trouble knowing what their requirements should be, so what makes us think they would be any better at measuring what was done right? Maybe our people managers could do the measurement, but if we're shared resources, would they even know? Our project managers might be able to do this, but if you're like me and have seen requirements produced by project managers, you're probably frightened at even the thought of that. (No offense PMs, you'd HATE my project plans!)

Having other BAs rate your requirements accuracy might be a possibility, but it that is a fox guarding the hen house. The possibility of collusion among a group as honest as BAs is still high, even if it is unintentional because you don't want to be seen as disparaging a fellow practitioner's work product.

What other problem methods do you see that would be really bad bonus structures for BAs? Let us know in the comments. Stay tuned for the next post in this series which discusses Project Managers and their bonus structure.

11 July 2010

BA World Melbourne 2010

Hello readers,

A brief note that I'll be at the BA World conferences in Melbourne (next week) and Sydney (August) this year.  

I am not doing any presentations but will be around to talk about my team's experience adopting agile over the last 2 years. If you are interested in my case study look me up.  I am happy to share.

In case you don't know me personally here's a head shot.  I'm the one in the red shirt.

9 July 2010

Process Speed (You Make the Call) - RESOLVED

In the first half of this post, we looked at a service contract department whose contract entry time had doubled. Now lets see what we did to get the data entry time back under control.

At first glance, this would seem to be another situation of a system implementation gone awry. It looks like the project team really messed up the implementation of the new contract management system. But did they really?

We know that only one of three teams, the smallest team in terms of personnel, is having an issue. The other two much larger teams really like the new system and all of the advantages it brings. We know that the contract team is capturing twice the amount of information they were previously, which leads to a lengthier data entry process for this specific team. We know that the company's revenues and customer service levels are hurting due to the backlog.

Our Suggestions

First, we adjusted the training material to reference a process with fewer steps. The contracts team had already discovered how to shave off a few steps in the process to cut their entry time and their suggestions were sound. This would save time for new team members, but was already reflected in processing times for existing employees.

Second, we made recommendations on ways the application could be improved in the future to shave some time from the process, but the suggested changes were actually very minimal. With our changes, we felt we could reliably shave 30 seconds from the 10 minute process, but we could not decrease the process to 5 minutes, the time claimed for the old system.

Our last suggestion was to give the process time. That might seem to be an odd suggestion until you understand contract renewals. Customers generally renewed their service contracts on a yearly basis, but it had only been 6 months since the CRM system had been implemented. While all the old contract data was converted into the new system, the number of data elements that were missing from the old system were half the total data required in the new system. Most of the additional contract entry time was taken up by filling in this missing data. By the next year, more than 80% of the contracts entered would take significantly less time to renew because all needed data would exist in the CRM tool. In the short term, we suggested making use of contract labor to process the easier to process contract renewals.

When the process times for the division as a whole were taken into account, total labor time actually decreased with the implementation of the CRM tool. Only five employees had increased labor time while 225 saw a decrease. The entire point of a CRM tool is knowing your customer, and by forcing entry of customer data at the start of the process, contract entry, the rest of the division saw great savings, plus customers generally had a better overall experience when interacting with the company.

Options We Discarded

The first rejected option was to contact each of our customers who were not yet up for renewal and get the needed information and have a temporary team do nothing but 'fill in the gaps.' The problem with this was that most customers hated doing inventories of their products at renewal time and were unlikely to do a supplemental inventory mid-contract just to fill out the gaps in our information. We expected a really low response rate were we to try this, so it was deemed a waste of time to even pursue.

Next, we suggested that the invoice printing and processing be sent to an outside vendor who specializes in mass mailings. We suggested modifying the system so that the documents automatically printed at a remote site and not in the contract entry personnel's location.

Lastly, we discussed an option that was eventually enacted once labor costs went too high. The entire department was outsourced to a low cost region where the company had established a regional office. Margins on extended warranties usually need to be large to support the infrastructure to support the warranties. With a high labor cost for data entry and a market that couldn't tolerate any price increases, the company was left with little alternative than to shrink overhead or reduce their service. Maintaining service quality won at the end of the day as that was what was important to the customer, not the nationality of the person entering their contract.

So how did you do? Did you think of alternatives that we did not? Do you disagree with our decisions or reasoning? Let us know in the comments!

8 July 2010

Reality isn't that simple

7 July 2010

Who wants to write this requirements document?

Al Pacino is a great actor. In 1992, he played a blind colonel in the movie Scent of a Woman. I won't go into the plot details, namely because I've never seen the whole movie, but there is one scene that I have seen. Al's character takes a Ferrari for a drive, which isn't a big deal until you remember, the character is blind.

So what does that have to do with business analysis? Consider this article that popped into my news reader this morning about a new, nonvisual interface for driving a car. Now, stop for a moment and imagine yourself on the university research team who came up with the idea. How do you go about eliciting requirements for such a project?

It occurs to me that most of the work done by business analysts in some way involves sight. Sure, we occasionally toss in a requirement for an audible queue or some tactile response, but when was the last time any of us, outside of a few disciplines, worked primarily on a nonvisual project? Even if you're working on data interfaces or ETL, you still likely drew up an ERD and made something that was primarily a function into a visual representation.

So how would an ERD sound or feel? What if we made all of our screen mockups using elevation relief mapping techniques so that blind people could get an idea of what our screens looked like? How would these thoughts change the way we work?

Its good to think about these questions, even if they do seem a bit silly, if for no other reason than they allow us yet another viewpoint of the work we do. Consider that relief map idea... if we're making mockups to help draw requirements from our stakeholders, what needs to be the focal point of our diagrams? The submit button? Specific data entry elements? Or is it the way the entire page leads our eye to one area that the user needs to see? If we consider the high points on the map to be the important information and it is surrounded by low points, does this make sense in drawing the user's attention to that spot? Maybe, maybe not, but if we consider all elements of the page as 'flat' because they're on a screen, we're probably not helping the user to understand what elements are more important.

So what about you? What are some 'crazy' viewpoints you've brought into your project lately?

6 July 2010

Process Speed (You Make the Call)

This is another entry in our semi-regular series You Make The Call. Below you will see a scenario that is based on a real situation that happened during an actual project. We present the scenario and then ask you, our loyal readers, to respond in the comments section as to what you would do in this situation. After a few days have passed, we'll post a wrap-up detailing what actually happened and how successful (or not) of a resolution there was to the situation. As always, suggestions for system resolutions are often a part of the solution, but the solution usually has a large process component to it as well. Without further adieu, here is our new scenario.

The Contract Team

The extended warranty team in your company is under pressure from upper management to shorten the length of time it takes to enter a contract for an extended warranty. In the last half of this year, their time to enter a contract has doubled from the first half of the year. You are asked to help out that business area and to determine where they can save time and get the contract entry process back down to the previous durations.

Your first meeting with the manager of contract entry shows you a man who is frazzled from the backlog of contracts waiting to be entered. His staff of five contract entry personnel seem as ragged as their boss. As you talk through the problems, you find the manager has three large concerns. First, the spike in duration for contract entry time coincided with the replacement of their old mainframe-based contract entry system with a new, web-based CRM (Customer Relationship Management) tool. Second, every day that contracts are delayed in going through the entry process, that is another day the company is delayed in collecting revenue. Lastly, a customer service problem is on the rise because customers who have submitted contracts for renewal but have not yet had their extensions entered into the system and are failing to receive service.

After meeting with the manager, you spend time shadowing the contract entry team members. While you watch, you have your stop watch out and track how long it takes to perform each step in the process. On average, most contracts only cover two or three pieces of hardware and can be entered in under 10 minutes. Of that 10 minutes, 3 minutes is spent entering customer information, 3 minutes entering product information and 4 minutes to print the invoice and mail it to the customer. The old system is no longer available, so you can not compare timings before and after the CRM implementation.

You gather example contracts from the old and new systems and notice that the total number of data elements has doubled on the new contract. It seems as if the amount of information captured during contract entry has significantly increased with the implementation of the CRM tool. You discuss your findings with the contract manager and he agrees with your assessment.

Other Voices

As a last step, you interview managers from the Call Center and the Service Repair departments to see if they are experiencing similar backlogs during their processes as well. Surprisingly, you find out that processing times in both of these areas have decreased since the implementation of the CRM tool. The call center's 200 agents and the repair team's 25 technicians are all averaging slightly lower processing times. These two teams offer glowing praise for the new tool and how much visibility they have to data about their customers open calls, call history and contract status; data they did not previously have access to see.

Now you sit back at your desk and wonder where to go from here. Why would the processing time of one team spike so dramatically when none of the other teams seem to be having a difficult time? Your report is due in a few days so you better get writing!

1 July 2010

Uncertainty, Physics and Intuition

"Yeah, that sounds about right."

"Those numbers are pretty accurate."

"Oh, no, I didn't look at the data, that's just what I know happens."

If you're like me, statements like those above make you cringe in horror whenever they issue forth from the mouth of a stakeholder. Gut instincts are often great for directional guidelines but are not sufficient for precise analysis.

Despite the necessity of precision analysis for quality decision making, precision in a vacuum can blind us to the direction of the changes that will occur due to our process or system changes. Its during these times that the 'gut' instincts possessed by those who are intimately familiar with the processes, those 'cringe' statements at the top of this post really come in handy.

There is a concept in physics called the Uncertainty Principle. In short, the more specific your information about exactly where a particle is located in space and time, the less you know about its velocity. You have two options and you can only pick one: you can know exactly where something is right now or you can know where its going.

When I read this article earlier today about probability, I was instantly reminded of the previous paragraph about the Uncertainty Principle and how all of this impacts project analysis. What our gut tells us can often be misleading, but close enough to act as a starting place for our analysis. The difference between 1/2 and 1/3 is close enough when we're looking for a direction to take our project, but once the real analysis begins, we must move past the approximation and truly focus on finding out the real answers at the root of the problem.

The article also gives us a few guidelines for doing this analysis, although they are not specifically mentioned. First, find experts in the field. Don't just go to managers and directors who think they know what goes on, find the people who are closest to the data, who do the process every day, and ask them.

Second, get a second opinion. Sometimes experts can interpret the data or perform the process in different ways. Its always helpful to have someone else look at your conclusions as a sanity check.

Third, challenge our assumptions. As Yuval Peres points out, where we start our analysis often times biases the outcomes that can be reached by our analysis. Never be afraid to start over at a different location if your answers seem to fit the question too well.

So what about you? What other ways have you found to challenge your own analysis?