31 March 2010

iPad Killer App for the BA

Earlier this month, I put up a post about ways in which the iPad could impact a BA. One of the things I really want on the iPad is a way to do easy process flow diagrams. Today I saw a preview video which made me think of another app for the iPad that could be really useful: mockups.

There are people who will argue, with some validity, that a BA does not do mockups or prototypes. I disagree, mostly due to a principle called IKIWISI (I Know It When I See It). Most users I have worked with can not articulate exactly what it is they want, but give them a rough drawing of your interpretation of their idea and they can immediately tell you what they like and don't like about it. That's not to say a BA does final design work, especially art direction, but basic layout tools can be an enormous help when eliciting user requirements.

It is from that viewpoint that I present to you iMockups for iPad. Check it out:



I love this. Its touch friendly. Its minimal. Its something I can draw on with my users right in front of me. Its something I can make a snapshot of and stick right inside of a requirements document.

That's not to say I'm ready to purchase an iPad, mostly because I do mockups about once every 6 months and the investment for an iPad just to do mockups would not show a significant return on the investment. Still, I find the concept very fascinating.

Do any of you see the possibility of using a tool like this in your job? Let us know in the comments.

29 March 2010

The BA and Social Media

On March 18, I gave a presentation to the Louisville, Kentucky chapter of the IIBA about the ways in which Social Media impacts the BA. The audience really seemed to enjoy the conversation (and conversation is one of the big themes of the night) so I thought I would share it with all the BetterProjects.net readers as well.

While I think I put together a nice presentation, this one was nearly obliterated during the conversion from Apple's Keynote into PowerPoint format. I cleaned up, split apart all the transitions and added speaker notes for everyone to see, but you really lose a lot in the translation. While I embedded it in this blog post, I suggest you go to slideshare.net and download the presentation to see all the information contained within it. Also note that slide 4 is a video that has been removed as it was too large to fit in the presentation, but if you click the link you can go watch the original.

Slide decks are nice, but if you're using them correctly, the meat of the presentation isn't actually on the screen, but found in the interaction between presenter and audience. Still, I hope you all enjoy the presentation and you find it useful to you. Feel free to redistribute it and or mix it up to suit your needs. That's the whole idea of social media!

24 March 2010

local optimization

The other day Ted wrote a book review on The Elusive Quest for Growth. In the review Ted applied the economic principles and lessons to the project domain.  In particular he addressed the issue of local optimization, where fiefdoms can interfere with larger organisational goals.

Today Kailash also posted on the same theme.  His article is a summary and review of Conway's Law;

An organisation which designs a system will inevitably produce a design that mirrors the organisation’s communication structure

I have worked in organisations that are very mission focused and in places where it's hard to tell who's in charge, let alone what the mission is. And for that matter I have also worked at places that have one clear boss who doesn't have any apparent vision of where the organisation needs to go.

In an agile project, and in fact, in any sensibly run project the goal of the project leadership should be to clear away impediments to the team delivering value at the fastest rate they can.

So, in this context, very soon after some fundamental technical blockers are cleared for the team the next and longest challenge in anything other than an optimized organisation is going to be in aligning the stakeholders with the goals of the sponsor.

No easy task.

I mention this because when I read articles and books on scrum and similar approaches to project management this is often omitted.  This goals is not only large and hard, it also takes a lot of time (money) and emotional investment.

Given that these issues are fundamental to organisational culture and structure is it any wonder that so many projects don't achieve the goals they set out for?

Picture by MariaChily, CC @ Flickr

22 March 2010

Project Competencies

Dan at Arras people has published this diagram with an explanation.  Looks interesting doesn't it?  Read more at the HTMAC blog.

What BAs can learn from Sports Fans

Football season is done. Hockey is going strong and basketball is winding down. Golf has started and Baseball is not far away, either. Beyond the general outlines of the sports seasons, the basic rules for each sport and each sport's business model, I don't really know much at all about sports. While I was a huge sports fan during my formative years, especially of basketball as I grew up in Kentucky, sports just isn't something that captures my attention. However, sports fans do capture my attention very well.

It has always been amazing to me how much something as seemingly simple as hitting a small white ball with a stick can capture and enthrall the minds of so many people. It is simply amazing to me that people who might never have played the sport, even as children, can be so concerned with the outcome of every play or possession. There are people that memorize the box scores of every game of multiple teams for entire seasons. They have the brain capacity to recite statistics for games and seasons that happened decades ago.

So with those observations in mind, I'd like to discuss a few lessons that BAs can take from our committed sports fanatics:

Winning is (isn't) everything

As I said earlier, I grew up in Kentucky, and if you know anything about fans of the University of Kentucky Men's Basketball, you know that they expect to win every single game of every single season. Losing is not an option in this state. Don't believe me? Google for commentary of former coach Billy Gillespie versus current coach John Calipari, and you will understand the difference between a coach who wins most of the time and one who wins all the time. While UK fans would be classified as 'die hard', they are also very unrealistic. All sports fans want their team to win, but most understand that in all major, recognized sports, someone has to lose.

As BAs, its also important to be on a winning team. Thankfully, its our job to make sure that there are no 'losers' in our projects. Sure, everyone may not always get exactly what or everything they want, but our goal is to make sure that all our stakeholders 'win.' That's not just a feeling of winning, or making sure that each stakeholder gets a share of some project pie, but true wins. Even if a stakeholder walks away from a project with nothing that directly changed in their area, if they understand how teams that impacted their business area did receive changes that made the stakeholder's world better, then a win did occur.

You need Talent

One common theme you find that ties together winning teams is talent. Having it does not guarantee success, but not having almost assures failure. That's not to say that everyone on your team must be a superstar with the ability to play for the 'Pros', but enough talent to be a constant and reliable contributor to the team.

BAs need to have talent as well. Some skills can be learned, but some people just have innate talent for certain tasks or roles that make them ideal for certain jobs. When I am on a project, you want me involved in communication, stakeholder relations, process diagrams and product demonstrations. These are areas in which I am highly skilled. BAs need to know how to do a lot of different things, but at the end of the day, know your talents and how to employ them effectively. As Michael Jordan found out the hard way, being a superstar at basketball doesn't make you a masterful baseball player.

Always be on the lookout for people who might have talents that your team is lacking. If you keep getting tripped up by details, find someone who loves to pour over documents looking for clues and holes. Find someone who knows how to organize a process and will relentlessly focus on crossing every T and dotting every I.

Your favorite team is someone else's nemesis

Every fan has some team they care about at least a little bit more than all other teams. Most every fan also has some team they wish never played another game. Many times the majority of fans for one team dislike some other team.

Know that your project is your favorite team. You devote yourself to it, you pour yourself into it and you would do anything to see it succeed beyond anyone else's wildest dreams. At the same time, there is someone else out there on a different project who thinks your project is the biggest waste of time ever conceived. If your project loses all its resources to their team, they will be ecstatic to see you fail.

As BAs, we should strive to never let poor gamesmanship enter our minds. Just as we work hard so our team wins, we also need to hope everyone else's projects are equally as successful. Even if we are competing for shared resources, nay, especially when we are competing for shared resources, we must focus on the fact that each team's win is not just a win for that team, but for everyone involved in projects in general and for the company as a whole.

Conferences are Important / Play above your Peers

Just as UK has been a perennial basketball powerhouse, they have also been a perennial football also ran. Its not that the football team is especially untalented, although there have been some really bad seasons, but that its competition is usually filled with superstars. The Southeastern Conference (SEC) is a football conference, despite the presence of a basketball team like UK. Because UK has historically focused more on basketball than football, even the best football seasons for the school have been lackluster given their tough competition.

But one thing playing such incredible competition does do is that it forces you to step up and bring your best every week in order to not be completely blown out. My first project as a BA taught me the very same lesson. The project was high profile, it touched almost every part of the business and the money involved for the project was more than most small companies made during the same time period.

With the future of the division on the line, we were under constant stress to perform at our best. Yes, we were the top talent from all over the division who were brought together to win this game, but the consultants we worked with on a daily basis were some of the best in the industry. If we didn't bring our 'A' game, we would go down. Hard.

It is in situations like that where I believe we learn the most about ourselves as analysts. While I went into that project with a lot of domain knowledge, my BA knowledge and skills were rudimentary at best. By watching the experienced BAs and consultants work their magic, I learned so much about what it meant to be a great 'player' in my chosen profession.

So what about you sports fans out there? What lessons can true fans like you teach us about being a BA?



Picture courtesy of Kentucky Sports Radio.

18 March 2010

Conflicting Incentives and other Economic Principles

The Elusive Quest for Growth: Economists' Adventures and Misadventures in the Tropics

One of my all time favorite books is by William Easterly and is entitled The Elusive Quest For Growth: Economists’ Misadventures in the Tropics. I read this book as part of a class in grad school and whenever I'm in a BA role, the book is never far from my mind. While I’m not an economist, nor do I ever wish to be a practitioner of the ‘dismal science I found that many of the broader issues Easterly discussed also apply to large projects

The one thing that Easterly hammered over and over in his book (in a nice way) was that people respond to incentives. He proposed that the reason countries in the tropics had not significantly increased their wealth was that the developed countries were providing tropical countries the wrong incentive(s) to improve. Easterly talked through population control, education initiatives, technology implementations, corruption cleanup and numerous other ways economists thought would provide incentives for countries in the tropical region to improve the lives of their citizens, all of which failed to reach their goals. None of the ways in which economists believed would foster growth led to anything more than a temporary reshuffling of the deck of poverty cards. Economists never gave the people and governments of tropical countries reasons that would make the inhabitants want growth.

As project people, we must constantly be looking for ways to engage and enable our customers to better themselves. If at the end of the project, we don't walk away with an improvement of some kind that outweighs the cost, we need to ask ourselves if there was really a need for that project. We must find and build a case for why the incentives will work to bring about the change needed in the organization.

If at first you don't succeed...
The next lesson to learn from Easterly is that there is no magic bullet to solving a problem. Economists looked for years to find the right way to bring prosperity to the peoples of the tropical countries, only to find that there is no right way (although there are many wrong ways).

Its the same with being a business analyst. There are adherents to traditional waterfall, to Agile, to SCRUM or whatever methodology of the month happens to have captured the fancy of some executive. No particular methodology is a substitute for possessing the skills, knowledge and experience of a quality business analyst. Knowing how to create the most accurate and detailed process map ever seen, yet being unable to explain that map to a customer is as much a recipe for failure as not knowing how to create the map in the first place.


Invest Wisely
Sometimes, being behind the curve is really being ahead of the curve. Easterly discusses how countries that are very far behind the technology curve often find it easier to catch up than those who are much further along (but still behind) the cutting edge. The large investment in new infrastructure requires a payback period in order to be a good investment. If there is no initial infrastructure, creating from a new slate can be easier because there is no owner of existing infrastructure who sees his or her livelihood being taken away.

The same goes for projects. Companies that have never had structured processes or enterprise systems have often just made due with whatever paper or Excel documents they can create ad hoc. Giving these groups any sort of system or any standardized process can seem to be a god-send into their life of chaos and disorder. Contrast that with trying to implement a new system into an environment that has had a system, even if that existing system fails to meet fundamental needs, and you'll see what its like when real chaos ensues. Its not just the old 'people fear change' metaphor at work, but the investment of time, money and knowledge in an old system or process can be a very large roadblock that must be removed before the new can replace it.

Storming the Citadel
The final lesson I'll highlight is that there are many ways to kill growth. Easterly discusses how closed economies, stifling governments and repressive banking policies will keep poor countries poor. These things are not only caused by ignorance on the part of those in power, but often by corruption and greed.

In projects, we deal with the same type of power brokers (usually on a much smaller and more petty scale), but to many people in power, any hint of change is a threat to their base of power. As analysts, we must always be mindful that our stakeholders do not always have the best interest of the project, the company or themselves at heart. What they may see as the right path could be horribly detrimental to everyone involved. It is our job to find out why these individuals are behaving in such a manner and to diffuse their disruptive and destructive behavior.

I highly recommend you picking up Easterly's relatively small book. It is a quick and engaging read, even if the subject is economics. If you're like me and love vacationing in the tropics, you'll come away with a new appreciation for the plight of the citizens who live in such beautiful locales. If you read it with an eye toward business analysis, you'll come away with lessons that will guide you through the rest of your career.

17 March 2010

Requirements Documents in an iPad World

One of the items which I have intermittently struggled with as a BA is how to properly format requirements documents. It has always frustrated me that requirements documents created in a word processor are tied to the default paper size for their country and how spreadsheet requirements documents are tied to no format at all. What I desperately want is an electronic requirements format that is formatted to my screen. When I say 'my screen', I don't mean the monitor on my desk at work, but the screen of whatever device I happen to currently be using to view the document, be that my dual 20" desktop monitors, my Dell laptop monitor, my MacBook Pro or my iPhone.

This article by Craig Mod, about how the iPad could change book layouts, really got me thinking again about requirements documents layouts. Any time I get a chance to speak with new BAs about requirements documents, I always end up spending a large quantity of time discussing how to properly format a document using the built in tools provided by all modern word processing and spreadsheet programs. I do this to 1) save their sanity from the quirky editing rules built into these applications and 2) to ensure their stakeholders sanity when reading these documents.

Why is there not a way for me to simply take text, mock-ups (images), diagrams and matrices (what I consider to be the 4 foundational blocks of requirements documents) and let the requirements application do the formatting for me? How much time would I save this way?

Wouldn't it be great if we could create project artifacts that contain the required business information but without any formatting? Each artifact could then be viewed in whatever format is most appropriate for the device which has opened the artifact. If you're trying to print, all the information rearranges in such a way as to fit the paper size used by your country or geography. If you're trying to view on a mobile device, the graphical content is viewable inline as a reduced quality graphic (so as to shorten the download and rendering process) but can be tapped and zoomed for additional detail. A device like an iPad would allow the textual elements to fill the space of the screen, just like a printed page but using the device's native screen size and still allow for zooming in to view the detail of diagrams and data sheets.

Its not only formatting that could be improved in this new world but also how we manage requirements would change if all project members had a device like the iPad. What if I could shadow a person who has a very mobile job, keeping a Visio-like application open the whole time, dropping in an action box every time they performed a new step in a task? This is something very difficult to manage today with a laptop as when you're moving around a lot, you need someplace to set down the laptop to be able to use it. The iPad simply has less of this type of limitation when it comes to mobile content creation.

I see devices like the iPad being the future of our profession. My laptop is an indispensable tool for me as a BA, but if anyone ever creates a 'killer BA iPad app' like I have described, then I would buy one of these devices in a heartbeat.

What about you? What ways do you see the iPad being useful (or not) in your projects?

16 March 2010

Mindmapping PM



I was thinking about ways to introduce the ideas in PM to someone totally new to the ideas - like a new project sponsor or executive put in charge of a project unit.  This is my first pass at layering the ideas.  

What do you think?

(Click on the image for a full view)

Defending your position


Today I had a meeting where a project stakeholder kept on highlighting additional things for us to do.  My instinct is to justify that our existing plan is fine and that his concerns are not a priority.

Of course that instinct is wrong, and I know not to follow it, even though I can still sometimes be drawn into arguments.

I've seen it before with 'masterful programme directors'  doing document reviews and PIRs.  It is simply hard to let feedback wash over you without you wanting to justify yourself.

Of course the substance of the comments are secondary.  And while they may be relevant and important or they may be totally irrelevant you are not going to be able to assess it at the table.

Even more importantly, you'll damage your relationship with the people giving feedback.  They are doing you a favour by offering your their insight. Be gracious under pressure.  You never now what you'll discover.

14 March 2010

Read BABOK on Google books (for free)

Google books has the BABOK available for free online reading.

I think this is a great idea from the guys at the IIBA.  Congratulations IIBA on sharing knowledge rather than restricting it to those that can afford to join the club.  It highlights the altruistic nature of the organisation.

12 March 2010

How much do your project stakeholders appreciate your work?

Listen to this story and think about how and why project stakeholders react to your project outcomes.


Experience is only part of the story.  Memory, and it's related but different perceptions of what really happened is another - even more important - part.

PM students

On Tuesday I start another semester of teaching PM to a bunch of students enrolled in a Masters of IT.  I've been doing it for two years so far.  This is my third.

Teaching is an interesting job.  It's tiring lecturing and delivering all the time.  I am still working on maturing my delivery so that there is less talk (by me) and more action (by the students.)  The great bit is working with people who want to learn.  (Which fortuitously I also get at my day job.)

If you are relatively new to this blog you may not have seen the slide decks i put together.  If not, take a look at it over at Slideshare.  Share it with our team if you think they'll find it useful.

Kano analysis and Bernoulli’s error

By now we should all have an idea what Kano analysis looks like. There are basic, performance and excitement classes of requirements. You generally have to work your way through the basic ones before you can start to address the other categories.

I have been reading Daniel Kahneman’s work on decision making and found he’s got some concepts on the importance of reference points for decision making. He talks about “Bernoulli’s error.

Are you with me?

I’ll back up two steps and cover the “Bernoulli’s error” concept here.

Basically this is the guy who gave us the normal distribution. The thing he came up with is decision making ‘should’ be based upon logic and rational thinking. It’s also fixed on a particular reference point (i.e. the day you analyse the situation and make a decision) and the decision extends into the future.)

So, an example; You need to work out the best car for you.  The Aptera 2e may be the right choice. It was always the right choice, and it always will be. At least until a better car comes along.

But.

If you are already driving the ZAP Alias, the decision to migrate to the Aptera may be a different one that if you are driving something a little older.

The mistake that Kahneman identifies and articulates is that our reference points change over time. What we perceive as valuable, or risky today, is different from the past and will be different in the future.

Kano recognises this and sees that what can be an ‘exciter feature’ today will eventually be commoditized.

Another example for the business casers out there. A return on a project of $10 million a year sounds okay now, but what if a better opportunity comes up later? Does our decision to go for $10Mpa stand?

And at the more detailed level, a system requirement that sounds like a basic and mandatory feature today might become irrelevant later, as more becomes known about the way users interact with the system itself.

Of course you eventually have to commit to something and you can’t just keep abandoning projects or requirements as something better comes up. You have to be able to see where you are and where your next step will take you. Divining too far into the future is pointless and results in ‘analysis paralysis.’

11 March 2010

What tools do you use?

In Jan and Derek's article I linked to yesterday there is a set of statistics from the IIBA 'Practices survey" from 2008.

"Whilst the most regularly used diagramming technique was flowcharting (63%), when it came to formal diagramming notations, use case led the way (55%) followed by data flow diagrams (42%), activity diagrams (38%) and context diagrams (34%). Entity relationship diagrams were still widely used (30%) and BPMN came in at 13%."

These tools and their spread is interesting. Something to consider is the likely response bias. The IIBA is still a relatively new organsaition and so the respondents are likely to be people who are particularly engaged in the development of the BA community.

I suspect the respondents are a little more experienced than the average, probably a little older as well.

Does this mean the survey is biased towards older, less modern techniques?

And if so, does this mean that there are a set of proven and pragmatic tools that are being ignored by the newer generations of Business Analyst?

10 March 2010

What is a Business Analyst, by Jan and Derek

Everyone that writes on the role of the business analyst eventually has to cover their take on what the role actually is about.

One of the best articles I read when doing research for my own position was by Jan Kusiak and Derek Brown. Last year I met Jan at the BA World conference and had a friendly argument about the value that a BA should provide.

My take went straight to the top of the startegic apex. A business analyst needs to be able to link their contribution to the organisational mission.

Jan countered with the fact that BAs develop their career over time and usually come out of frontline operations areas, first as an SME in either a business area of technology domain. He explained that a fledgeling analyst needs to master the basics of the role; communication, systems thinking and so on, before elaborating and extending their capabilities.

It takles a while, it seemed he was saying to me, for a typical analyst to really build their skills to a level that gives them the ability to get to where I think they (we) should be operating.

Fair enough. Everyone has their own path.

Anyway, RQNG has just published an updated version of Jan and Derek's take on "What is a BA."

If your work with business analysts, if this is your job today, or if you want to become a BA this is a great read.

Gary Hamel on Knowledge as a competitive advantage

These points lifted from an article by Gary Hamel from late last year;

  • In every industry, there are huge swathes of critical knowledge that have been commoditized—and what hasn’t yet been commoditized soon will be.
  • Given that, we have to wave goodbye to the “knowledge economy” and say hello to the “creative economy.”
  • What matters today is how fast a company can generate new insights and build new knowledge—of the sort that enhances customer value.
  • To escape the curse of commoditization, a company has to be a game-changer, and that requires employees who are proactive, inventive and zealous.

Given this argument, what are we doing to make our work more creative?

9 March 2010

What's in Your Blog Reader?

One of my favorite things about the Internet is how so many random pieces of information can converge upon my life. My web browser is the window through which I view most information that comes my way. I'd like to share with you a couple of interesting people who have found their way into my news reader in the last year.

What's my mantra?
First up is Alan Cooper, whose company has a blog, but it was their book that was brought to my attention by an article in my news feed. Cooper wrote The Inmates are running the Asylum and one of his key points, nay his mantra, is to always remember that the end user is not like me. Each of us have a key set of assumptions and filters through which we view our world and those assumptions and filters are not likely to be the same set used by our stakeholders.

Think about it... if I said to you that I want a sandwich for lunch, what exactly would that mean? If we know each other well, you would likely guess the fast food joint and possibly even the meal I would purchase on any regular day. But what about on those 'non-regular' days when instead of a hot pizza sub, I want a club sandwich at a sit-down restaurant? Even my best friend would have a hard time guessing where and what I want to eat, given all the possible meanings to my stated desire of a 'sandwich'.

The same principle applies to business analysts and our customers. We all have been told at one time or another that our end users don't actually know what they want, but its the job of a BA to 'elicit' or 'draw out' their true needs. We spend our time trying to dig down to the root of a problem, then help the stakeholder either find a process change or the development team a system change to address the need. Sometimes our customers have easily defined problems ("When I click this button I get an error") but sometimes the issue is not so clearly defined ("I need to know more about my customers"). If the BA uses only their own filters to tackle the problem then the answer will be very unlikely to resolve the customer's actual problem.

It all comes down to finding the right perspective or lens through which we can view the problem. I remember my very first project as a BA, being brought in at the very end of the project to write process documentation and training material for the business unit in which I had spent the last three years as an employee. My first thoughts when seeing the new application almost ready for implementation were, "This system is so bad my friends are going to hate me when I demo it for them." Even though there were people who had spent years on that project, who had also previously spent years in the business units, they had used the mental filter of a pre-selected software package to view the problems found in the business area.

While many people recognized that the proposed application had issues, no one was willing to put a stop to the project even though it would have been detrimental to the business area to switch them to the new program. I breathed such a sigh of relief when the project was eventually canceled, knowing I would never have to stand in front of my colleagues and present a 'solution' that was a bigger mess than their problems. Had someone taken a look at the problems of the business area prior to selecting a vastly inferior software solution, the company might not have wasted so much time and effort on a project that was doomed to fail.

What is efficient?
My second insight comes from Jeff Atwood, who runs codinghorror.com, and is about the concept of system optimization. Being a programmer, Atwood has a passion for producing well-formed, elegant code. Being a programmer who understands and tries desperately to meet his customer's needs, he understands that having the most efficient and maintainable code does not equate to having the most effective product for his customer.

One of the things I appreciate most about Atwood is his ability to see more than just programming standards and guidelines, but to see how the use of those tools can improve the applications he creates for his customers to use.

One of the traps that I find good developers often fall into is not seeing the difference between well written code and code that meets the customer's needs. Having code that executes flawlessly, that crunches numbers in record time and does all this in a way which can be easily maintained by any novice developer is a good thing, but if the software does not help the end user reach their goals, the application is still a failure.

I remember one conversation with a developer who deviated from the design document to make what he thought was a trivial change, all in the name of system efficiency. It sounded good on paper as he'd save a few processing cycles and the end user would not notice any difference when using the application. The developer neglected to realize two very important facts about the repercussions of making that change. First, while his change improved the code efficiency, it did so needlessly.

We're talking microseconds saved on a transaction that already took less than a second to process.

This transaction only occurred a few times per month and was performed on a server whose average load was around 10% and whose maximum load was 50%. In other words, the developer spent more time redesigning something that would have worked just fine as designed than would ever be saved by making the change.

Even then, the change wouldn't have been a big deal, until you realize that if the functionality in question ever had a problem, the support team would now have considerable difficulty in trying to get the user up and running as quickly as possible.

The new implementation was technically correct, but prone to misdiagnosis by the helpdesk. Sure, training could possibly help, but remember how rare the transaction occurs and then remember the turnover rate for a support team and you'll realize that whenever this function does receive a call, no one who takes the call will likely have been trained on how to handle this one-off situation.

When the helpdesk tries to resolve the issue as they would any other similar problem, the steps they would take that would have fixed the problem under the original design now will not work. Not only did the developer not add value with their change, as there was no perceivable benefit to the user, they actually introduced additional support costs, all in the name of code efficiency.

Your Turn
So what is in your news feed? What articles have you run across in recent times that may not be directly related to your job, but that gave you thought on how you might improve as a BA?

8 March 2010

Too Many Calls (Y.M.t.C.) SOLVED

Last week we started a series entitled 'You Make the Call!' with our inaugural entry being an problem for a call center manager having a difficult time with their call volume. If you haven't read the original article yet, read it before you read our solution below.


Misdirected Solutions
To the call center manager, the problem was call volume. There were too many CSRs needed and as more locations came on line, the call volume would only increase. The manager's suggested solution would cut the number of calls, thus decreasing the manager's cost, but it wouldn't really solve the underlying problem. The call volume is only a symptom of the real problem which would not be solved with the presented solution.

Others might suggest that having the point of sale system in the store keep a running count of inventory level and automatically notify the online system when it has reached a stock out or reserve stock level. By doing this, the calls are eliminated and the manager doesn't need to use their time to notify a stock out, either. While this solution could work, there are two issues with it: such an integration is expensive, especially if the inventory software in the store can not keep such a running tally. Second, this also implies that when products are sold in the store that the store knows exactly which items are sold. If the store sells nails by the pound, for example, it is considerably more difficult to know exactly when the store is truly out of nails.

What Really Happened
So what was the real problem? We've been alluding to it the entire time, but the real issue here is inventory management. The store is suffering from stock outs, but no one at the store level seems to be concerned that they are potentially forgoing sales because of a lack of product. If the store doesn't have the item in stock that the customer wishes to purchase, they are potentially missing out on sales.

In this situation, you should start by enlisting the store operations team and helping them determine the exact reason the stock outs have been happening. Is the store not managing their inventory correctly? Is the incentive for the store to maintain a minimum inventory amount keeping them from being able to sell products the customer wants? Is the store intentionally not stocking certain items they don't want to sell and then repeatedly calling those products in to the call center as 'out' in order to never sell them?

Your Turn
So how did you do? Did you come to the same conclusion we did? Do you like the idea of this series? Do you have a great scenario you would like to write and present? Let us know in the comments!

4 March 2010

Too Many Calls (Y.M.t.C.)

This is the start of an irregular (in more ways than one) series that we're calling 'You Make the Call!' The idea is that we'll present a situation that you might find in any given project. These situations will come from real projects but with the names and details changed to protect the guilty.

In the comments section, you answer 1) Your opinion on the real problem and/or 2) How you would go about solving it. After a few days have passed and everyone who wants to has had a chance to comment, we'll post a review of the answers, will explain what actually happened in the situation and, most importantly, what should have been done. So, with no further introduction, here's scenario #1...



Too Many Calls
You work in the corporate office of a medium sized retailer. This retailer has franchise locations all over the country, along with a large presence in online sales. What makes this retailer unique is that products ordered online are not shipped to the customer, but are picked up at the local store. The products ordered are very customizable by the customer and the stores pride themselves on their quick turnaround time for orders.

The call center manager for the website asks to speak with you about the large volume of calls they receive on a weekly basis for stock outs in the store. Stores will run out of product to sell, will call the online support center and ask for the products to be put on hold in the online system until the next replenishment order is received from the warehouse. The manager estimates that half of their CSR's time is involved with handling stock outs.

The online ordering system has no knowledge of the stock levels at a store; it only knows which items the store can sell, not which the store is able to sell. The call center manager suggests that it would be great if the store manager could be given access to an abbreviated web form, similar to the one used by CSRs, so the manager could update their own inventory availability without needing to call the online support team.

You Make the Call!
The ball is now in your court. What is the underlying problem in this situation? What do you suggest to the call center manager to help with the large volume of calls?

3 March 2010

On project management blogging

When I started this blog there were only a couple of dozen project blogs around. Now it seems like I discover a couple of dozen a day!

And many of us are talking around the same themes and ideas. For example, many of us rail against bureaucracy or bloated control processes at the expense of the team’s motivation, enthusiasm and desire to get things done.

Frankly, I have to question myself about the value of this blog today. Am I still contributing, or is this space just another part of the internets noise?

Way back when this blog was in it’s infancy I decided to focus on the role of the business analyst rather than on project management, to provide it some sort of differentiation from the project blogs that were already out there. But today there are plenty of outstanding BA blogs.

And my focus has broadened beyond my initial focus into scrum and technical pm practices, mainly because these are the things I am working on and thinking about as I go.

So, what’s in it for me these days?

I don’t seek to monetise this blog (although I have added some affiliate links) and I haven’t tried to leverage my online reputation in my day job.

On the other hand I do get to engage in some interesting discussions with my peers around the world, which I don’t get to do with my peers in the building. And by engaging in a professional community I get to learn.

I also force myself to articulate ideas in relatively clear language, which for me is important. I haven’t yet tackled the really important discussion – which is about dialogue with sponsors and stakeholders. Sometimes I think the project blogging community is all about project teams talking to themselves in a closed environment. That’s not really what we are about.

Sometimes I also think that the PM and BA blogs are operating in two different worlds. One a couple of occasions I have asked questions in PM and BA forums what the readers think about the other role, but usually just get a generic answer that, at least to me, says the answers aren’t really thinking about the potential conflict and collaboration embedded in the partnership.

2 March 2010

Upgrading your Skills

One of the things that I really love about most technology is how relatively easy it is to upgrade it. A little searching online for the correct part, loosening a few screws, swapping out a few circuits and, presto!, a machine that is new again! Wouldn't it be just as great if it was equally as easy to upgrade our own project skills?


Early on in my career, I understood that the reason so many of my managers had been stuck in their positions for so long was that they were still using the same tools and methods they had learned in college or the first few years of their career. It wasn't that my managers were unintelligent, it was that the world had moved while they had remained still. When I had this epiphany, I made a resolution to never let my skills stagnate and drag down my career progression.

Traditional Methods


There are numerous ways in which we can keep our skills sharp, many of which are methods we've known about for years, but may have forgotten in the hustle and bustle of daily life.


Almost every town in a modern society has access to a community college or university. These places of higher learning provide different methods for professional workers to take classes and earn credit for their efforts. Whether the classes are taken with a specific degree in mind or are they are taken just for specific domain knowledge, the knowledge gained is very valuable. My MBA courses provided me a wealth of knowledge that I still use on a daily basis.


If you do not have access to post-secondary education, you may have access to local training providers who may have training courses that could aid you with your training needs. These institutions don't provide degrees, but will often have training paths for specific skills (Project Management, Business Analysis, User Experience, etc), often leading to recognized certifications. These institutes usually require less time to achieve a certificate than a university would to attain a degree and they often have more flexible class hours than a more traditional school.


Lastly, if you don't have internet access (how are you reading this, btw?), you can always pick up a bound, dead tree (these things called books) and read your way into a more knowledgeable future. Your local bookstore or library likely has a wide ranging selection of business, process and technology books waiting for you to lay hands upon them.


Modern Methods


Its possible that none of those traditional methods either meet your schedule or your needs in terms of training. Fortunately for us, these methods are no longer our only options. The internet age has opened up all kinds of new options.


It is possible that you don't have access to schooling at either of the previously mentioned types of facilities, but if you're reading this, you do have access to a computer and thus, can participate in online learning programs. There are many online education providers who, for nominal fees, allow access to their catalog of training programs. These programs cover everything from traditional training programs down to office and secretarial skills.


The next option is a service called iTunes U. This is a great service, provided by many of the top universities in the world who have recorded lectures by their professors and luminary guests which are then provided to the public who can download the content for free. The subject matter of the lectures cover a very broad range of topics, allowing us to learn whatever suits our fancy and at our own pace.


Another method is  MIT's Open Courseware, a project sponsored by the Massachusetts Institute of Technology, where the school's course materials are posted online for free. There are many business and technology classes available for review. Syllabus, lecture notes and suggested readings for many classes provide a wealth of knowledge from some of the brightest minds in the world.


Because you're reading this, you likely already know that there are many blogs and websites that can provide a wealth of knowledge for free or at a minimal charge. Many of these websites update with new written content on a regular basis. A few sites provide podcasts or video content if text articles are not your preferred method of learning. Sites that offer podcasts are great for those of us who have long commutes or who travel for our jobs. Most of these sites also provide a news feed which you can use in a news reader, so you are alerted whenever new content is published on the site.


The last modern method is actually the same as the last traditional method, but with a twist. Books no longer require a dead tree due to electronic gadgets like Amazon's Kindle, Barnes & Noble's Nook or the Apple iPad. These devices allow you to take hundreds of books with you wherever you go and make it incredibly convenient to enhance your skills whenever you have a moment of time.


So these are the methods that I put together on ways to enhance your skills. Have you used any other methods that I didn't cover? Share it with us in the comments!

Image courtesy of wikimedia.org