30 November 2010

We've all got our own schedule problems!

Gene Roddenberry talks about tight deadlines and the lessons he learned in the early days of Start Trek in this letter from the wonderful website "Letters of Note"
Now, about the length of the pilot, etc. I agree it should be shorter and should be paced differently. It's my fault that it wasn't since I let myself be swayed by an arbitrary delivery date and did not take a day off and then look freshly at the whole picture before it went to negative cutting. This will not happen again. In future, of the two risks, I will risk violating contract provisions rather than sending out product readied only through weeks of sixteen hour a day fatigue. Where the agency can help here is early in the planning of a pilot, leaning hard on the network in those primary stages where they waste three, four and five weeks getting back to you with approvals on this and that. This plays a very large part in ending up with production dates which are bound to create problems.
Click through to the website to see the whole letter.

Note how he took ownership of the problem and articulated his personal solution.  Nice one Gene!

29 November 2010

The Simple Enterprise

I'll admit, in my 9 years as a project team member, I've been guilty of this sin many times... I've added complexity needlessly to applications when it would have been much better if I had given my customers a simple, flexible process. Now, there have been many instances of this happening where I wasn't given much choice in the matter as my users and their management demanded it, but I wonder if I could have found a better solution that did not require a flotilla of developers to create and maintain.


The most memorable is a project I was on a few years back for a large, multinational corporation. There was one specific requested feature that the European business representatives demanded be included that I just did not see any value in including. I wasn't alone as most of the representatives from the rest of the world thought the idea simply crazy. Since the first rollout was to be in Europe, the functionality was put into the initial release. When I left the company 18 months later, this vital, critical, utterly important feature, which took several months of developer time and several more months of analyst time, had not been used once since go-live. Given the schedule delays and cost overruns that plagued that project, I continually point to it as a project that could have done with a great deal less complexity.

Experiences like that project have taught me to value simplicity, even if it is difficult to achieve. That is why I have come to value articles like this one in TechCrunch from Box.net founder Aaron Levie. There are many great quotes in this article, so go read it all, but there are a couple which really struck home with me:
And while no one explicitly desires cumbersome technology, we keep buying it because we’ve built a strong correlation between the number of features a solution has and the likelihood it will solve our problem. That, and you won’t get fired. 
Isn't that the truth? How many times have you heard someone quote, "You never get fired for buying IBM." I'm not poking fun at big blue, but the sentiment is that the more complex an option you purchase, even if it is complete overkill for what you're doing now, you give yourselves options for the future. While that might be true, what you're really doing is saddling yourself now with a high cost structure that must be maintained for the life of the application.
This bias isn’t limited to technology buyers or builders – the analysts I speak with often focus more on feature comparisons and product matrices than end-user experience and customer success
The analysts Aaron was speaking of here were industry analysts, not business analysts, but sadly I've seen the same behavior out of both groups. We get this idea stuck in our heads that what our users really need is this one cool new feature we read about somewhere on the Internet that some startup is trying and we then shove that into our enterprise application where it is nothing more than an ugly wart on the side.
Building simple technology is not easy; it inherently takes much more work to reduce complex problems into simple solutions for people. Building products that suck is far easier
So true. Its easier in the short term just to capitulate to the solution someone brings you than to really sit back and dig through the problem to find a simpler solution to the problem. This may not be a bad thing, if the solution they bring is already simple and fits well into your application, but that's not a common occurrence, in my experience.

My Solution

There are a couple guidelines I like to use in my goal of building more simple enterprise applications:

First, think. No, I mean it, really think. Stop to do it even. Its a really easy trap to get caught up wanting to do everything for our stakeholders. My stakeholders generally love me because I bend over backwards to try and make them happy. However, new requests to add complexity or deal with rare edge conditions add a lot of complexity. There may be easier methods using existing functionality that, while they may take a few additional steps than what is 'optimal', may work just as well as they can be done now and not after the next release.

Second, aggregate. I don't know about you, but it is a very rare day for me when I don't get at least one new request for functionality from some part of the business. Most often the requests are nothing more than variations on a theme of something that already exists or something that has already been requested in a slightly different form. Don't create a new request for whatever comes in, but add it to the existing requests that are similar. When it comes time to implement that set of requests, look at how you can accommodate as many of those as possible, but in such a way that keeps the user from needing to making ridiculous decisions.

Let me give you an example of this one... a particular application I once worked on had a few hundred different ways, when all the configuration options were used in combination, to simply find a price for an item. This was a nightmare for testing and making development changes, something that had plagued the development team for years. When we were tasked with finding a new solution to replace the existing enterprise application, I was determined to find a solution to this problem. I studied the existing user base and found there were really only 3 primary configurations used. It made sense to then focus our efforts on these 3 commonly used configurations, not the hundreds of potential combinations.

Third, return the investment. I've almost always had fantastic users and sponsors. They care about their business areas and want to see them succeed beyond anyone's wildest expectations. Often times they are so caught up in their vision of what might be that they fail to see the price it would take to make their dreams come true. Anything, given enough time and money, can be automated, but not everything should be automated. If a user has a great idea for something that currently has an acceptable manual process because it only occurs once every few months, this probably isn't a good candidate for automation, unless the downside of failing to do it correctly the first time is so large that your business would crumble. Always ask how much money and time does it take to do this now, how much of both would it take to do it in an automated fashion and what is the risk difference between the two alternatives.

Lastly, select or build an application which allows for changes to be made administratively. This does not mean toss in a bunch of parameters and allow users to set up whatever they want. It does mean build a logical method for allowing rapid change to occur within the business without the need for the IT group to pull all-night coding sessions. There are a few tools which will allow you to do this: workflow engines, business rule expression evaluation engines and addition/modification of user interface fields and layouts. None of these three items are trivial to build, but they provide a wealth of payback. Instead of spending time with each release tweaking report and screen layouts, along with their underlying database and coded logic constraints, you provide a framework for users to build their own logic and then support only the implementation of the framework.

So those are my ideas on how to make your applications simple. What other ideas do you guys have?

27 November 2010

Making the world a better place!


In early November I left the team I have been working with for the better part of 3 years to return to Melbourne and take on a new job.

I have joined some colleagues who run a consulting agency around the BA practice.  It's even called Business Analysts.

The part of the business I am involved in is reviewing the BA team's general capability and working with them on improving, on reviewing troubled projects and helping them get out of the red zone and some project start-up work where you aren't sure what you next step should be.

It's all around helping you do better with the people you have.  And of course I couldn't do it without the help of the excellent leadership team at Business Analysts either.

So in the course of the next few months expect this blog to shift gears right into the middle of mainstream BA work as that's where my head is going to be, (and Ted's already is!)

26 November 2010

Projects Fail

A few months ago I took a look at the popular whipping boy for failed projects, not to try and clear the good name of requirements but with the intent of making sure we all looked deeper at the causes of project failure than what we're told in surveys. Its always good to know that someone who has led a very high-profile project that failed validates my instinct that requirements are not the cause, but just one of many causes, for why projects fail.


Wesabe, an online personal finance application that went under earlier in 2010, failed at many things. Its co-founder, Marc Hedlund, takes a detailed debrief on why his company failed. His primary reason for the site's failure? Poor technical decisions and implementation. The second reason? A poor understanding how how to meet users needs, but not what their needs actually are. The entire article is worth a read, but I'd like to point out a couple of things that really spoke to me from what Marc said:
You'll hear a lot about why company A won and company B lost in any market, and in my experience, a lot of the theories thrown about -- even or especially by the participants -- are utter crap. A domain name doesn't win you a market; launching second or fifth or tenth doesn't lose you a market. You can't blame your competitors or your board or the lack of or excess of investment.  Focus on what really matters: making users happy with your product as quickly as you can, and helping them as much as you can after that.  If you do those better than anyone else out there you'll win.
I think back to all the products and software I've purchased over the years that I have dearly loved and one thing really jumps out at me... there was a nearly instant attraction to it that I was unable to shake. In short, they did make me happy, even if that happiness came not from what a great product it was but from how I felt about the purchase. It didn't matter if the product helped me be more productive or more knowledgeable, but it had to satisfy some inner itch that nothing else could scratch.
I am, of course, enormously sad that Wesabe lost and the company closed. I don't agree with those who say you should learn from your successes and mostly ignore your failures; nor do I agree with those who obsess over failures for years after (as I have done in the past). I'm hoping that by writing this all out I can offload it from my head and hopefully help inform other people who try to start companies in the future.
Failure hurts, but it teaches if you don't obsess over it, incorporate its lessons, and most importantly, share that wisdom with others. Thank you Marc Hedlund, for taking the time to share with us.

23 November 2010

You Make the Call: Dave leaves the project

Dave’s role was the second business analyst on a large multi year software development project. His main role was taking the lead work the primary BA gave him and converting it to documents that would be later reviewed by both business stakeholders and the vendor.

Dave’s work was about the detail, the follow through and ensuring the BA work conformed to the enterprise quality standards.

His partner in crime, Sheila, was the lead BA. She was the visionary, the big picture thinker and the personal networker. She brought people together and unified them so that they were all focused on the project goals. He strengths were in the people things and she did a great job of it.

Sheila, in the first few weeks of the project had scheduled a series of workshops with the project stakeholders and then followed up with interviews and coffee shop meetings relentlessly until she had earned everyone’s respect and trust by demonstrating an understanding of their stake in the project outcomes and empathy for the costs and difficulties they were going to face together as the project changed the existing state of play in the organisation.

She was charismatic and full of energy. She had a natural charm that enticed the stakeholders into a conspiracy where they were all in this together and would all share the weight of responsibility for project outcomes.

Dave’s job was to follow up, document, test the ideas and validate the details with people. It was easy work as Sheila had enlisted people into the vision of project. Everyone was invested in its success.

Dave cruised through the days wondering at Sheila’s fantastic performance wondering if he’d ever be as good an analyst as Sheila. Sometimes he wondered whether he was even needed on this project. It felt like all he was doing was taking Sheila’s notes, although it was true that he did occasionally spot logical gaps or conflicts in business rules and occasionally highlighted functional deficiencies. But for the most part Sheila was awe inspiring and Dave really did wonder whether he would be missed.

When development began the same sort of things started to happen. Sheila started off by bringing in the whole development team from the vendor and giving them a presentation about the company’s mission and purpose and how the new system was going to contribute. She clearly broke down the scope boundaries on the product and explained why some very appealing and easy to implement features were to be deferred. She talked about the key features and how they would be elaborated over time to fully round the solution out over several releases.

Dave supplied everyone with the documented details to complement Sheila’s PowerPoint and presentation.

Sheila and Dave stood in front of everyone and took questions. The more experienced developers asked a series of detailed questions about features and target benefits, about how certain user interactions were envisaged. Sheila and Dave took turns answering them, Sheila often leading in with an answer and then deferring to Dave for the detailed follow up. Sheila knew all the answers, but was very encouraging of Dave and wanted him to get the recognition he deserved for the work he had done in modelling out and developing the system specifications.

The project kicked off and Sheila went into stakeholder management mode while Dave stayed in close and regular contact with the developers. Dave answered questions and checked in with Sheila daily on where the dev team were and what sort of things they were asking about.. Sheila shared feedback from the stakeholders, occasionally directing some minor change to a user interface or some elaboration of a feature.

Things were going well. The developer team were picking up momentum and building a great product. They were feeling thrilled to be working on a project with such a good client team. Clear about what they wanted, easy to talk to and flexible when it came to minor details.

The Dave got the call. His mother was ill and was probably going to die. He had to take leave and disappear for a while, possibly months.

The project manager, Karen and Sheila got together to talk about how they would handle Dave’s absence.

Here are the facts;
  • Sheila and Dave both knew the specs and the maturing solution very well, but Dave knew much more about the details
  • Sheila was also at her best doing the big picture-people thing and would feel stifled and frustrated pouring over specs and test cases, besides the project stakeholders constantly need contact and it took almost all of her time to keep everyone informed about where they were and aligned to the project goals
  • Hiring someone new now would be a challenge. The market was tight so there could be some time to get a suitable person. And it would take weeks for someone to come up to speed. 
  • There were only about 10 weeks until the next major release. This was the third release and the team tended to pump them out quarterly. There was a subsequent release coming up, and Dave had already done most of the spec work for that.

What would you do?

22 November 2010

How Complexity Leads to Simplicity

If you're unfamiliar with TedTalks, I highly recommend checking them out as there is a lot of great material there. This recent mini-chat with Eric Berlow is no exception. This talk illustrates very well a principle that I try to follow in my life as a business analyst.



An example of how this plays out in the life of a business analyst...

There is a project that we're starting at work which has been on the table for a couple of years now. Everyone believed that the project would be worth our time doing, but there wasn't a good business case that could be made for it as there would be no measurable increase in income and only a minor decrease in cost. There were numerous intangible benefits for doing the project, but few quantifiable benefits.

One of the development managers who was recently brought into the discussions, but who had not been included on the discussions of the last two years, started making statements to the developers about their vision for the solution. That's fine, except that their view of the solution 1) required a large number of intermediate tables to be created and then maintained for the solution to work and 2) displayed that data in a way with which would be unfamiliar to the users of the new application.

Its not that the development manager's solution was bad, it was just needlessly complex. Once the developers and I had a chance to talk and I explained the actual prototype I had reviewed with the sponsors, you could see the light go on in their mind as to how what I was explaining was considerably less complicated, if no less complex.

What was the difference between the solution I presented and the one presented by the development manager? Mine eliminated complexity while maintaining ease of use for the user by mimicking a screen they were intimately familiar with. Yes, the other solution could potentially, but not guaranteed, make for a relatively fewer number of mouse clicks but only at the cost of considerably more complex code and a larger price to maintain the application in the long run. In return for this minor potential gain in low cost user efficiency, it substituted a guaranteed higher cost to develop and administrate.

So what about you? How have you worked to eliminate needlessly complicated processes and systems in your organization?

19 November 2010

The Problem with Applications

Recovering the filesystemsphoto © 2005 Jared Klett | more info(via: Wylio)
About 10 years ago, I was one of the new hire trainers in my technical support department. It wasn't a full time job, I still spent most of my time answering the phone, but I was incredibly grateful for those 2-3 days each month I didn't have to wear a headset. The two years I spent training new hires saw our department go through an interesting transition regarding the skillset that incoming technicians possessed. During the first year, most of the new hires had a good understanding of how to use the command line in an operating system, while those who were hired in the second year had mostly never seen anything but a graphical user interface.

This was the late 90's and early 00's, so graphical user interfaces had been the norm for some time. I had started using a PC when DOS was used more than Windows but even before that, I had used an Apple IIe which was almost completely text based (except for a few games). I knew how to use a command line, yet suddenly my trainees did not. A significant portion of our troubleshooting tools required knowledge of DOS and command line tools, so I was tasked with making sure the new hires had this knowledge by the time they left my course.
The problem though is that more and more computer users do not have the underlying knowledge that most programs and operating systems assume them to have. This leads to an innumerable amount of problems for those of us that seek to, or are begrudgingly drug, into supporting these users.
I used to love mucking around in the command line or hacking my computer's registry, but as I've spent more and more years on projects developing software, I have come to realize that most users should never need to do either of those things. If applications are designed and developed correctly, user configuration should be near zero. Its this conclusion that makes articles such as this one at The Brooks Review hit so close to home for me:

The article continues by saying that by simplifying the applications we build, we also require less of their time to educate themselves about how the application works. Yes, a program like Adobe Photoshop will always be complex, but if Adobe spent time to make it less difficult to use instead of just adding more functionality with each release, they could improve their user's productivity.

This is a lesson that all of us who work on projects with a software development aspect need to understand. Corporate applications seem to be, at least from what I have seen, significantly more difficult to use than most consumer applications. The next time you use your company's expense reporting application, hold up your iPhone next to it and consider if filing an expense report is more difficult than it should be. Now hold that iPhone up next to the last application you helped gather requirements for, created a project plan for or developed code for and ask yourself, "What would I do differently to simplify this for my users?"

17 November 2010

Lead by example

How can the team know what is right or wrong if you don't lead by example?  What are some simple and concrete things we can do with our team mates to help set the tone?  If I were to hand you a checklist it might look something like this;
  • Set clear priorities
  • Deliver the right sense of urgency to the team
  • Be clear about accountabilities
  • Encourage people to escalate problems quickly
  • Clearly define the qualify standards you are working to
  • Discuss the ethics and values that you and the team have
  • Identify barriers to cooperation
But these are the things that are important to me and are based on my experiences and values.  What's your list?

16 November 2010

Entrepreneurship for the enterprise

We enterprise folk can learn a lot from the start-up community.

The Business Model canvas is a great way for getting people to lift their horizon's above the details.  Even process models have their shortcomings, and giving context always helps in understanding.

Take a look at Steve Blank and Alex Osterwalder's latest presentation

Successful entrepreneurship 1
View more presentations from steve blank.

15 November 2010

The Class I'd Like to Teach

178/365 One small step for essay kindphoto © 2009 stuartpilbrow | more info(via: Wylio)My college English Composition teach was fabulous. Dr. Dennis O'Brien is a man I will never forget, not for his ability to teach the English language, but for his hilariously quirky personality. But sadly, those two semesters taught me more about his love for Star Trek Klingons and his loathing of the term 'Alternative' to describe a musical genre than it did how to actually use the written and spoken word.

It wasn't until after I left college and began my first job as a business analyst that I realized how truly unprepared I was for a career where I live and die by my ability to communicate. Yes, part of the reason I got the job was that, when compared with many (but definitely not all) of my colleagues, my written communication skills were far beyond theirs. That isn't saying much, however.

It is this reason why I agree with Jason from 37signals that a college education doesn't always do enough to prepare us academically for the future. Jason goes on to discuss a class that he, and I as well, would like to teach to college students:
It would be a writing course. Every assignment would be delivered in five versions: A three page version, a one page version, a three paragraph version, a one paragraph version, and a one sentence version.
This is what I, as a business analyst, do every single day. I take the detailed business information that stakeholders provide (3 page version), I condense and distill it to something that can fit in a project charter or a requirements document (1 page version). Then I take that and further condense it into a project overview (3 paragraphs) which will get rolled up into an executive summary (1 paragraph version) and eventually make its way into a PowerPoint slide (one sentence version).

Being able to condense while retaining meaning is not a trivial skill, nor is it one that was taught (at least not officially) by any university I've ever seen. But it should be, especially in today's world of knowledge workers. This is one of the main things I see which holds back project team members from advancement. If they are unable to effectively condense and convey meaning for a project, then they also fail to communicate the value they themselves provide to the organization.

12 November 2010

Chevrolet uses IBM's Rational platform for the new Volt Vehicle

Chevy Volt Conceptphoto © 2007 Neal | more info(via: Wylio)According to a report at TechCrunch, US car maker Chevrolet has been using IBM's Rational platform during the development of the new Chevy Volt.

As explained in Monday’s press release, GM used IBM’s suite of Rational software products (which includes design and simulation tools) “to develop some of the Volt’s critical electronic controls for the vehicle’s innovative battery system, electric drive unit, and cabin electronics.” According to LeBlanc, IBM’s software allowed disparate engineering teams to collaborate, put products to the test and it helped them model and better understand how various electronic systems would interact.
That’s a significant departure from the past, when GM’s engineering teams would develop components independently, with minimal sharing during the development process.
First, kudos to Chevy for embracing a collaborative approach to design. The company has for too long been saddled with an overly hierarchical structure. Lets hope that this is just the first step towards a more effective development process for them. Also, kudos to IBM for making a very high profile software sale

While that quote is nice, it isn't the one that really caught my eye.

IBM and GM revealed new details on Monday on the car’s electronic backbone and how it came together in 29 months, from concept to finish.
29 months for a project from start to finish. Is that good or bad? Yes, it is less time than most complete new car designs for an auto manufacturer, but is it something to brag about or not? Two and a half years is still a very long time, especially while the company is going through a massive bankruptcy.

Two things that are not said in the article are 1) was 29 months ahead, on or behind schedule and 2) how did the project do against its projected budget? These are far more fascinating questions to me as they would tell us a lot about GM's ability to actually execute its plans.

How would you rate GM's progress as shown with the Volt?

10 November 2010

Delivering value

Consider these two lists of project management requirements

List 1
  • Be innovative
  • Be flexible
  • Manage and lead individuals
  • Develop a sense of loyalty to the team
List 2
  • Be predictable
  • Perseverance and determination
  • Work as a team
  • Organisational loyalty
Here's a starting place to think about potential conflicts in your team's values.  Doe things in List 1 contradict list 2?  Is rthere a grey zone in the middle to be discussed and understood?

8 November 2010

Measuring business analysts

Hi readers,

Today I was asked a question to which I didn't have a ready answer. Maybe you could help.

What measures of analysis/analyst work will most help BAs focus and improve their contribution to project outcomes.

And if you have recommended metrics, what would you say is a good score?

Some examples that spring to mind include number of change requests and BA work as a % of total effort. Any better ideas? Do these ones suck?

Thanks for your help!

Published with Blogger-droid v1.4.9

Richard Branson on Calculated Risk

Virgin founder Sir Richard Branson during the opening keynote at CTIA Wireless in Las Vegas, NV.photo © 2008 TechShowNetwork | more info(via: Wylio)It really blows my mind when I read an article by a very successful business person and realize that what they're talking about is something that I've done without even consciously understanding that I'm doing it. Richard Branson's take on risk is a perfect example of this:
In life, it's better to stick to a few simple values and aims; the same holds true for business. One guideline that we rely on is that if a new business has the potential to damage your brand in any way, you should not invest in it.
Several years ago, for my 30th birthday, my wife and I went skydiving. Lots of our friends thought we were crazy for jumping out of a perfectly good airplane with nothing but a large piece of canvas to keep us from becoming a messy spot on the ground.


To us, it was a calculated risk. My wife and I both place a high value on new and exciting experiences. I wouldn't say we're risk takers or excitement junkies, but we both want to go different places and try new things. When skydiving came up as an option, we did the necessary legwork to ensure we had a credible diving school and that they followed safety standards. Once we were assured, we signed up and had a great time.


This was a calculated risk. Yes, there is the possibility that neither the primary nor backup parachute would open, but the possibility of that occurring was so minimal when compared to the joy of the experience that we could not resist the opportunity. We calculated the risk, found it to be small in relation to the activity and signed up.


I see that projects are really the same thing. You recognize a need or an opportunity. You check to see what risks are involved. You check to see what rewards the company will reap for a successful project. You compare the two to see if your calculated risk is large or small. If the risk is small, you take the leap.


Over the years I've seen too many risk/reward scenarios complicated by adding in extraneous detail that frankly isn't really anything but a stakeholder feeling the need to make themselves known by bringing up a lot of 'potential risks'. Yes, thinks happen on a project you need to prepare for, but adding the need for a plumber to be onsite 24x7 during rollout because the project team will be dumping too many coffee grounds down the break area sink is frankly ridiculous. Yet, I've seen so many similar risks (ok, not quite as absurd, but you get the idea) added to a potential project for no other reason than the stakeholders are attempting to kill something they just don't want to do, no matter how good it would be for the organization.


So that's why I like Branson's approach; its simple and gets to the point. Its not that a deep analysis isn't needed, but it isn't as needed as many people believe it to be. If it aligns with your business and organizational philosophy, if you can do something to add value better than any of your competition and you find a way to protect the downside, go for it.

7 November 2010

When initiating change consider this


Before beginning a project, a change request or any other sort of initiative consider these three questions:
  • What is the problem or opportunity before us?
  • Why is it important to us?
  • How should we measure the change?
By considering your idea against these three categories you get (at least) the following benefits;
  • You avoid picking a solution prematurely
  • You understand it’s strategic importance to the organisation
  • You are able to provide a baseline for measuring improvements and the cost of doing nothing.

5 November 2010

Taco Bell... Analysis?

Recently I read an article entitled Taco Bell Programming (link contains some rough language at the end, but excellent concepts throughout) in which the author, Ted Dziuba, has some interesting thoughts on development tasks that apply to business analysis and project management as well.

Taco Bell has 8 basic ingredients that, when combined in different ways, can be used to create their entire menu. That's pretty impressive when you think about it, because they can maintain a very small set of inventory items, yet produce a wide variety of products for consumption. Because the company is creative in the way it combines their inputs, most customers don't even recognize the repetitiveness in the menu.

Ted's basic premise as to why development should learn a few lessons from Taco Bell is two fold... first, reuse of existing functions that you do not have to rewrite and then maintain is better than creating new software that produces the exact same outcome. I couldn't agree more. I'll give you an example of this from my own life: how I approach a Work Breakdown session. We've all been in these, where we spend a few hours writing on post-it notes and tacking them up on the wall. Necessary, but really boring.

Whenever I'm asked to participate, I come in with a stack of 'boilerplate' tasks. There are certain steps which always occur, no matter what the project, so I come in with that set of tasks already written out and ready to go. I cut my time in the WBS to 1/3 of the otherwise needed time, just because its crazy to reinvent the wheel. That's not to say I don't add additional tasks that are unique to that project, I most certainly do, but those tasks that myself or my team do every single time always come with me in a stack.

The second premise Ted brings us is that unless there is a very compelling reason, we should prefer older and simpler tools over newer and more complex ones. Yes, using that new development tool can be sexy and may teach you a lot, but what do you lose by spending the time implementing a solution that could be done more quickly and with less risk by using an older tool?

To me, this is why BPMN just hasn't caught fire as of yet, namely that Visio flowcharts work just as well, if not better, than a BPMN tool. Why do I say that? Simple. Most BAs, and a large portion of our stakeholders, likely have seen and used Visio, while they likely don't know BPMN and don't understand what all the more complex (and more precise) stencils mean. BPMN 'looks too difficult' so stakeholders, and some BAs, dismiss it, even though there are some nice things the tools allow us to do.

Its just not the analysis side, either. There are lots of web-based project management tools out there which have a simplified workflow when compared with MS Project, but because most PMs and stakeholders understand MS Project, they stick with that tool. Its not that web-based tools are inferior, they usually are not, but Project is a known quantity which everyone can relate to (no matter how bad it is).

I must, in all fairness, point out one flaw in Ted's logic: Taco Bell's products, while cheap and easy to make, are not what most people would think of when they consider when looking for a 'quality' eating establishment. Menu ingredient simplicity does allow for quick and cheap, but when sophistication is really needed, it just can not be found at this location. There are times when sophistication is necessary, both in the culinary disciplines and with Business Analysis and Project Management, and we must remember to choose wisely when that need arises.

3 November 2010

Theory X

So, how do you manage a team with a variety of values and expectations from their interactions with management?

You know theory X and theory Y.
(X - managers and workers are adversaries, Y - Managers just nee to support worklers and they will do their best.)

I hope that we projects managers tend to fall into the Theory Y zone. Our teams have interesting work, usually good management and people are focused around common goals in a context of a cohesive team. I suspect we are much more Theory X than we think. For instance, my direction to my team to adopt scrum practices is not optional. Until reflecting you wouldn't neccessarily recognise this as a theory X appraoch to work. And we don't expect we are espousing values that say we don't trust our team members.

In fact, any time we mandate a process or control technique, that's exactly what we are doing. I want to be a coach of faciliatator, but I keep demanding certain practices and standards are followed. Deep down I know this is a problem, but how can I let go of the tiller when we are in rough seas? I don't think I can unless I know I have sipport from my sponsors. And my sponsors are in the same boat - manging expectations and dealing with a portfolio of risky investments.

Who makes the call that it's okay to experiment and fail? At what scale?

What are your stories?

1 November 2010

Business Analysis through Improvisation - part 4

Here is part 4 of Jonathan 'Kupe' Kupersmith's Business Analysis through Improvisation session during the September 2010 chapter meeting of the Louisville IIBA. Check out part 1part 2 and part 3 before viewing the below clip!