Search This Blog

30 January 2010

Steve Jobs on why Apple exists

This video just popped up in my newsreader and it was so good, I had to share with everyone. It encompasses so many of my thoughts for such a short clip. Steve Jobs is a guy you either love or hate (I am an Apple fanboi, so he's good by me), but no matter what you think of him, you have to admit he's very clear on why Apple exists as a company:

Now, having heard that, I ask each and every one of you reading this, can you articulate that well about why you are a BA or PM or ::insert job title here::? Are you that focused about what you do? If you are not, then what is holding you back?

29 January 2010

Defining Requirements at Apple

You're in the middle of an Apple PR tsunami at the moment, but bear with me while I share this clip. It's the first part of the iPad launch. In particular take a look at the first 2 minutes and the way Jobs introduces the product's place in the market and it's core capabilities.

This approach to determining requirements is the right one, for all of us on every project. We need a context for our IT systems and business processes and it needs to be grounded in something that our client/customer/user values.

We'll talk more about Steve soon. In the meantime, invest the two minutes and reflect on how your requirements fit into their context.

28 January 2010

BAs learning from other companies: Google, part 2

This is the second part in a two part post. Check out part 1 before reading this post.

Do a small number of things very well

When we think of Google, we think of them as a search company. While that is what got them their start, it really isn’t the big part of their business today. Now, they are an advertising company, and a really good advertising company at that. Search and advertising are the two primary things, the bread and butter if you will, of Google’s business. They are the core to the company.

To correctly target advertising, you have to know who your customer is and where you can find them. This is where Google’s search technology comes in to play as customers give up a vast amount of information on what is important to them whenever they search. The more Google knows about us as individuals, the more targeted the advertising they show us and the more likely it is that the companies placing the advertisements will make a sale. Google leveraged their search capabilities into making money by selling advertising.

Similarly, its good for BAs to have a couple of things they do really well. For me, it is my ability to communicate detailed and technical concepts into language that makes sense to my customers. My career started out in tech support, helping non-technical users to get their computers back in working order. The skills I learned in that role were a perfect fit into my transition to a BA.

Buy v/s Build

Despite being innovators, Google realizes that sometimes its better to purchase a company who already does something well than to fight against the learning curve and flounder for a long time trying to learn how to do something well. It is hard to admit that you’re not going to be able to tackle every problem yourself or that someone else would do a better job at tackling a particular issue, but Google has done a great job of recognizing these situations and then finding the people who have the needed expertise.

As BAs, the same situation applies. One of the BAs who works for me understands our company’s data on a level I can’t comprehend. When people ask me a question about a product setup, I often defer the question to the expert, instead of faking my way through an answer that might or might not be correct. The last thing I want is to ruin the relationship with my customers by telling them the wrong information when I know that the right information is easily accessible. It also builds trust in my entire team by building up my people as experts in their respective areas.

Don’t be afraid to fail

Google is not perfect. Not even close. When they first launched their web-based productivity suite, it was resoundingly panned as a massive step backwards compared to desktop versions from many vendors. It had limited functionality and it had poor compatibility with desktop suites. Pundits claimed it would never be used and Google was tossing money away on a terrible product.

The suite languished for a long time, receiving only stability fixes and minor functionality additions, until the introduction of collaborative document editing. Once customers began to understand that many people could edit the same document at the same time, the usefulness of an online productivity suite was realized. This was the ‘killer app’ that had been needed to show that this Google product was not an eventual failure.

Today, the applications still lack in functionality when compared with desktop versions, but the functionality divide consists of things that the majority of users never even knew existed in the desktop productivity suites. Google Docs has become a success, albeit a minor one, because of one feature that isn’t available on the desktop, even though in almost every other way it is inferior to older and more established products.

We BAs could learn a lot from that kind of mentality about failure. No requirements document will be perfect on its first (or often even fifth) version. No screen mockup can encompass all the needed functionality and interaction. No use case can cover all possible directions that a user may go. Yet despite knowing the limitations, we should not just toss up our hands when we don’t get it right on the first try. We learn what our customers really need and next time, we get it right. We look for that elusive ‘killer app’ that will win approval from our customers so we have it ready for them, exactly when they need it the most.

27 January 2010

BAs learning from other companies: Google, part 1

This is the first part of a two part article, focusing on how BAs (and really any person who is involved in a project), could learn from some of the practices of different companies. This is the first in a series of posts I intend to do on this topic, each focusing on a different company. Be sure to check back tomorrow for part 2.

Google is a very admired company, both for their excellent products and their financial performance. Besides those impressive feats, there are several lessons that business analysts can learn from a quick review of what got Google to where they are today.

Don’t be evil.

This is Google’s motto and driving aspiration. Many of their software predecessors (Microsoft, IBM and Oracle if you want to point a few fingers) had contentions and even antagonistic relationships with many of their customers. These companies often stated how ‘customer focused’ they were, but their actions often did not match up with their rhetoric. Google wanted to be different from these more traditional companies, and for the most part have succeeded.

Not being evil means a few different things. First, never abuse your power. If you get into a fight and throw your weight around, do so in favor of your customer and their needs, not strictly what makes financial sense for you. Google realizes that customers notice when a company is being overly selfish at the expense of their customers and they try not to exhibit such behavior.

As BAs, we do not necessarily have lots of ‘power’, but we do have a great deal of influence and responsibility. Never should we seek to use these things only to our sole gain. Our skills should only be used to the betterment of our customers (although sometimes that betterment is not what the customer believes will be the best) and by bettering our customers, we will in turn better ourselves.

Openness is good.

This one is actually a mixed bag for Google, one of the ways in which they fail at the previous point. Google is all about open. They use open source technologies and they regularly contribute their advances back into the open source community. Where they fail is that they only return technology that either advances their agenda or that doesn’t reveal a competitive advantage over their competition.

A good example of this is Google’s data center technology. Special built servers with custom cooling apparatuses power the Google platform, which presumably gives them a competitive advantage in cost structure over their competitors. The equipment they use is mostly off the shelf hardware, but assembled in a way that is different enough to provide real energy savings. Imagine if this same technology could be used by all data centers in all industries, how much energy savings could be increased. Google hasn’t released this technology because it gives them that advantage over other data center hosts.

Never be a hoarder of information and knowledge. Share the wealth. A great BA is one who enables and equips our customers and colleagues with everything they need to do their work in the most effective manner possible. It is up to us to facilitate the smooth flow of information to all corners of the organization, even beyond those we think are within our reach. We should always be striving to push back the curtains and throw light on problems and concerns.


No, not in the buzzword sense of the word, but I mean true innovation. Putting a different color of paint on the same car design isn’t innovation. One of the things that Google is great at is understanding where they started at, where they are now and how big the problem is they still have to tackle.

Back before the advent of Google, I remember how painful it was to find needed information quickly. Now with Google, it is a rare time when the information I need is not just a few keystrokes away. Despite how good their search engine is, it could be better. Eric Schmidt, Google’s CEO, stated in 2005 that the company estimates it would take 300 years for them to index all of the world’s information. That is a huge task and ensures their primary goal won’t be met for a very long time, unless they innovate to find ways to do the work faster.

For BAs, we should always be looking for ways to not only improve how our customers work, but ways we work. There are many more tools and techniques for managing requirements than there were even 10 years ago, but most of us continue to use word processing and spreadsheet software for that task. Its not that those tools are bad or even inappropriate, but when was the last time we even considered using a different tool? New web tools are released daily and some, like Google’s Wave, could completely change the way we interact with our customers and how we manage requirements. If we never step back from our daily tasks to look for new and better methods, we will be left behind.

26 January 2010

One simple step to better configuration management

Many say that configuration management is hard. It is. 100% correct, "as the books says" software configuration management is hard. It takes tools, skills, discipline and effort to build and support reliable and effective software configuration management process. It is especially difficult, when there is already some process in place and improvement involves change.

My experience shows that it is particularly challenging when it comes to non-source code items like documentation and release packages. Can you imagine following dialogs with project team members? I can…

Managing source code:

--Is it necessary to follow Configuration Management practices, when you work with the source code?

--Do you use source code control system during development?

--Would you start coding without SCC in place?
--Absolutely not!

Managing release packages:

--Should you manage configurations for you release packages?
--Oh, yes!

--The best way to do that is to be able to recreate any version of release package...
--Oh, yeah! That's the best way, especially, if you hook this up to automated builds and tests...

--Do you do that?
--Well... You know, that requires time to setup. We are so busy with other tasks actually writing software, so we never actually got to that... And, by the way, our existing process is not that bad...

--But still you can get all the previous release packages, right?
--Well, I guess so... We have a share where all the releases are uploaded.

--Do you delete files from there?
--I think so. When we need to.

Managing documentation:

--Should you keep track of the versions of all the development-related documents that you've got?
--Yes, definitely!

--So you do that, right?
--Well... Not exactly... You know SharePoint (or another tool, you name it) is somewhat difficult to use (or setup). We just put the file in a shared folder or sync over the e-mail. When the document is final, we put it into SharePoint.

--I see... But you do change version number on the document each time you edit and keep it somewhere, don't you?
--No, not really. Do we need to?..

Generally, the further you get from the source code the worse it gets.

There is a simple, not ideal, but simple remedy to this, which lies in mimicking what source code control system does:

Never overwrite or modify files! Always create new!

After all, we all have got 500Gb drives in our laptops - we have to put them to work.

25 January 2010

The way you make me feel

Consider these two statements;

"The project is late and over budget because our estimates were overly optimistic."


"We were overly optimistic in our estimates, and as a result the project is taking longer and costing more that initially expected."

The difference is probably coming across as more subtle that it is because you have the two sentences right next to each other.  Consider, though, that the emphasis of each statement is on the first part.

In the first scenario you are saying that the project is late and explaining (or justifying) why.  In the second scenario you are advising that your estmates were optimistic and explaining the consequences.

The way you speak affects the way I interpret what you say, and consequently, the way I feel about you and your work.

Picture by mynameisharsha cc @ Flickr

21 January 2010

Google Wave and the BA, part 2

If you haven't yet checked out part 1 of this series, please do so now.  We're in the middle of a discussion about potential Google Wave use cases.  Here's the second:

Collaborative Selling

  • A sales person creates a new wave and then adds his client/lead to the wave. They  marks the entire wave as private so comments in the wave that the authoring party makes available to everyone else in the wave.
  • The Google Voice (GV) extension is added into the wave. Because the client is already part of the wave and because the sales person has the client's phone number in their contact list, GV can read the client's phone # and allow the sales person to initiate a call right from within the wave.
  • The sales rep calls the client from within the wave and they have a conversation. GV tracks the total talk time, and once the call is over, creates a transcription and mp3 recording of the call and adds those as new blips in the wave.
  • The sales rep adds a new Document using the Proposal template to the wave and then marks it as public so the client can see it. The proposal template is associated to a Spreadsheet that contains all of the company's products so that all the rep has to do is select the necessary products the customer wishes to purchase from a drop-down list within the document. The client and sales rep collaboratively update which products and in what configurations the quote will include.
  • A technical question comes up that the sales rep is unable to answer. The rep adds the sales engineer (SE) to the wave to answer the question. The SE reviews the call history and proposal document and realizes they need additional information to properly answer the question. The SE adds a Calendar invite to the wave and sends an invitation to the client to have a conference call. The engineer then uses GV to call the client and answer the question.
  • When the proposal is complete, the sales rep adds a company created robot to the wave which reads the proposal document and pushes the order to the company's order management system for fulfillment.
  • The order management robot checks on demand for the status of the order and eventually pulls back in a shipping notification, along with a tracking ID from the shipper. The customer adds in a shipper's tracking robot to the wave and can see on a map, within the wave, the package's route and its estimated delivery time/date.

That's great, but...

So we've discussed a few ways in which Wave could be of use to a BA's customers, but is there any way that Wave may be of direct use to a BA? Absolutely! Lets talk about a few ways in which Wave may be useful to you as it matures:

  • Document collaboration = Just like in the example of the sales team and the Proposal, requirements could be managed within Wave's framework. No matter how you track your requirements, matrix, standard document template, user stories or whatever else, Wave will allow you and your customers to simultaneously modify and comment on the document. No longer do you need to worry with someone editing your content, because if they get it wrong, you can see what changes they made and put them back (or more likely come to a compromise).
  • Distributed teams = Developers in Delhi? Business in Boston? Deployment in Denver? Support in Shanghai? Imagine being able to pop in a GoToMeeting extension and record a video conference call, with saved video (courtesy of YouTube for Business) of everyone who attended. No need to reserve a conference room, now you need a headset and your laptop's built in webcam.
  • Search = We can't forget that Google's primary focus is search. You can now put all your information right into Wave and know that the world's most powerful search engine can rifle through your data and provide you with the needed answers in mere moments.
  • Interaction Design = While not strictly a BA task, many of us do find ourselves doing this function. You've already got a web browser open if you're using Wave, so why could you not add a web based design tool and interactively create a few site mockups?
  • Transparency and Accountability = Wave will allow you to be as open or as closed as you want or need to be. Your clients and customers have the ability to see all of your work all in one spot. Reviews can be handled within the document. Sign-off can occur for everyone to see (and for everyone to see who is withholding approval).

Almost... Almost... Almost...

If you have played around with Wave, you are likely wondering what version of the application I'm using because you haven't seen anything like that in time time you've spent with it. Yes, you are correct, little of what I have described can actually be done in Wave today. I implore you to give it time; they will get there. Google is trying to do something radical here, and the more radical it is, the more difficult to see it in its early stages. If the pull it off, and they are Google after all so there is little doubt that they will fail because any technical lack, it will change the way you work and play.

So what could break it? What could cause it all to fall apart? Here are a few of what I am calling 'stop signs' which could keep this wonderful world of wave from ever becoming more than vaporware:

  • Federation = You'll notice that most of what I've talked about is integrating different Google products together. Google is smart enough though to realize that while most people use them for search, most people do not use them for anything else. That's where Federation comes into play. Wave is more a set of technology building blocks that anyone at any company can use to connect up to Google's implementation, but other companies will have to build those links if Wave is to take hold in the marketplace. Imagine a world without airports and being the first person to build one. You can take off and land airplanes, but you always end up back at the same location. Without other people (companies) building other airports (Wave Federation), a single airport will not do you (much) good.
  • Complexity = Wave is a complex beast. The idea seems simple, to meld all of the existing applications into a single, cohesive framework, but if you do a quick look for reviews of Wave, you'll notice one thing they all say... what exactly is it? Many people are making Wave out to be a solution in search of a problem. If users don't see how Wave benefits them, what betterment it brings to their life and work, then it will fail.

I've presented in this post a view of what I think Wave will look like in the not so distant future. I could be wrong, but I believe that I am not too far off the mark. Don't believe me? Think about all I've said, and then take a look at some of the recent Wave developments I've linked to below, then tell me if you still feel the same way.

20 January 2010

Google Wave and the BA, part 1

This is the first in a two part series on how Google Wave might be of benefit to BAs in the future. This part is an overview of Wave and one scenario on how Wave might be useful to a BA's customer. The second part contains another customer scenario, a scenario on how BAs could use wave to manage requirements and a conclusion about why I think Wave is headed in this direction.

Unless you've been hiding under the proverbial rock, you've likely heard that Google has yet another new product under development. I know, another one? Don't they have enough already? So if you haven't gotten in on their latest technology preview, I highly suggest you start riding the Wave. (If you don't have an invite, let me know and I'll share the few remaining ones I have with whoever wants one.)

Before reading more in this article, its a good idea to get your brain wrapped around what exactly Wave is and what it is not. Instead of rehashing all of that here, I'll just point out a few links to articles written by different authors that cover the basics and the advanced. Go read those and come back; I'll wait on you. Patiently.

Now that you've familiarized yourself with Wave, you are probably wondering one of two things... isn't this email? or isn't this a chat room? If you're thinking deeply today, you might even wonder if this isn't just a new document collaboration paradigm. None of these seem really new, and they're not, but you are really just scratching the surface as to what can do and are not seeing what it is.

If I was forced to pick a single word to explain Wave, it would simply be 'glue'. That might seem odd, but you have to understand the problem place in which Google currently finds itself. Either through home-grown initiative (Gmail, Calendar, Desktop, etc) or through acquisition (Docs, Blogger, YouTube, Picasa, etc), Google's portfolio of applications has grown large and disparate. While your Google Account ties all of these services to you the user, these apps fail rather spectacularly at being tied to each other. For a great example of this, check out the Google Dashboard and look at all the individual pieces of information Google has about you, then think about how much information you've had to duplicate across each of those applications at one time or another. If you look at your account details, you'll see the common information at the top of the screen, which is not much.

So how does this translate into Wave being 'glue'? What Wave will do is allow you to connect all these applications together, bringing all of your data into a single unified view. So why would anyone want to pull all of that data together? I'm glad you asked because I'd like to outline a few usage scenarios for you that might one day (with the proper extensions) be available for you and your customers.

Event Planning

Lets say that your client is an Event Planner that has their own small company. One of the biggest issues they have is finding a way to keep all of their information about a job organized and consolidated so they can easily understand how much time it took them to create the event and what needs to be billed to the client. You suggest that they use Google Wave to solve their problems. Here's how you might do it.

  • The event planner creates a new wave and adds their client to the wave.
  • The planner needs a way to track who is invited to the party, so they add in the Google Spreadsheet extension, select a template for an event, add in pops a new widget into the wave. The client now adds names and contact information to the sheet. Since the client has their address book managed through Google Contacts, the spreadsheet knows how to pull all of the contact information directly from the client's account. All the client has to do is start typing and Google looks to see if there is a match between what is being typed and the entries on the contact list.
  • If the client doesn't have time to put the guest list together, they can always delegate that function to their assistant. Since the client uses Google Apps for Business, the assistant can see their boss' contact list and thus, add contacts from any user who has delegated contact access to that assistant.
  • Once the list is finalized, the planner pops in either an or a Google Calendar extension and links to the spreadsheet of guests. Depending upon what type of calendar entry the planner selected, one of a few options can occur:
    • The planner can send out an email blast inviting all the guests to the event. As guests accept or decline the invitation, that response is automatically pushed back into the guest list. If the response is a Yes or Maybe, then the guest could be prompted to ask if they want the event to be automatically added to their personal calendar.
    • The planner or client could add in a Google Voice extension that could initiate outbound calls to each member on the guest list and personally invite each person, updating the invite list manually with the guest's response. Because Voice has the ability to track all calls, the amount of time spent on each call is automatically logged for billing.
    • Lastly, the planner could add a Google Document to the Wave, select an invitation template and link to the invitation spreadsheet. This would create a mail merge where all the guest's needed information is pulled into the template. The document could then be printed by the planner or sent to a third party fulfillment house to be printed and mailed.
  • Additional spreadsheets could also be added to the wave to track expenses, location options and planning the menu.
  • A project timeline extension could be added as well, allowing all members to add tasks that must be completed during the lifecycle of the event.
  • Once the event is complete, a Picasa or Flickr extension could be added to the wave and then pictures of the events could be uploaded for the guests (who could be notified by another mail merge) to view.

All of that sounds really great, but how many event planners have a BA on call to help them put together something like that? Probably not too many. But one group of people that do rely heavily on BAs, especially in larger corporations, are sales people. The BA is often responsible for putting together the processes and systems that the sales team uses to track down leads, put together quotes and to process orders for the company's customers. What could Wave do for a sales team?

To be continued in part 2.

19 January 2010

YOUR NEXT MOVE: The Leader’s Guide to Navigating Major Career Transitions

Nilesh Raje has his articles published earlier with International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's generously agreed to write some posts here at Better Projects. Here is the first.

YOUR NEXT MOVE: The Leader’s Guide to Navigating Major Career Transitions
Harvard Business Press; October 6, 2009
220 pages, $26.95

Rightly said, changing position is a task that needs to be performed and not to be enjoyed. Should it be the latter then it is bound to detrimentally affect one’s career. A promotion often involves a whole new set of challenges, which even an astute manager may have difficulty in overcoming it. The way one performs in their new role or position can either make or break them in their career.

Dr. Michael D. Watkins, leadership – transition guru has recently released his new book YOUR NEXT MOVE: The Leader’s Guide to Navigating Major Career Transitions (Harvard Business Press; October 6, 2009) which tries to zero in on roadmaps to overcome the challenges associated with one’s move in the corporate world. The move could be one's promotion, joining a new organization, an international assignment, or taking charge of an organization during crisis.

Dr Watkins has explained the common eight types of career moves business leaders usually experience at some point in their career. This is by-no-means a definitive list of all the possible moves but could be considered as a reasonably exhaustive list. The eight common types of career moves, which have been covered as individual chapters in the book includes:

The promotion challenge – How to outperform the expectations of those who promoted you and excel in your new role.

The leading-former-peers challenge – When one is promoted to manage a team that were formerly your peers, accept the fact that relationships have to change and focus on what’s good for the business.

The corporate diplomacy challenge – The art of influencing others and building alliances, which are absolutely critical for getting the things done.

The on-boarding challenge – Transition into a new business unit or joining a new organization one must clearly identify individuals both inside as well as outside the organization who can help you in meeting your agenda.

The international move challenge – Leading international assignments it’s vital to effectively communicate with your subordinates from an unfamiliar ethnic culture and ensuring a smooth transition while relocating one’s clan.

The turnaround challenge – Taking over an organization that is in very deep trouble and figuring out issues with customers and competitors that have been threat to the business.

The realignment challenge – Define strategies one needs to employ to create the necessary changes in the organization before problems result in a crisis.

The STARS portfolio challenge – By the end of the first few months one needs to demonstrate substantial progress in motivating people and securing early wins.

According to the author each of the move revolves around two core challenges: Personal Adaptive Challenge and Organizational Change Challenge. Given your strengths, competencies and mind-set the personal adaptive challenge addresses what are the key personal shifts one personally needs to make when they get promoted? One should understand what new competencies one needs to develop. The organizational change challenge focuses on what one needs to accomplish in the business by identifying the current state of the organization and key stakeholders.

Dr. Watkins is the cofounder of Genesis Advisers, a Newton, Massachusetts-based leadership development firm specializing in transition acceleration programs and coaching. He also holds the credit for his international bestseller The First 90 Days: Critical Success Strategies for New Leaders at All Levels. The book tackles opportunities and challenges people usually face while moving into new positions and provide some useful guidelines to prove your mettle in the critical first three months in a new job. One can identify what type of position they are moving into and strategies required for succeeding in each of them.

15 January 2010

Use Case Videos

Okay people, I have moved on from Slide Decks to video. Here is the first of several videos on Use Cases.

If you found this interesting, follow through this link to the whole series by rmb190.

14 January 2010

BA tools stink, part 2

This is part 2 of a 2 part series on the state of BA tools. Be sure to check out part 1 before reading this entry.

Productivity Suite Landscaping

The typical office productivity suite has a multitude of applications that all do different things and provide different value to the user. Each of these tools has their uses, but the uses are broken up into different applications with different file formats. If I want to put a graphic file into the middle of a text document, I have to first create the graphic in a different application, save it to file and then import it into the the document processing application. To me, these is a needless set of steps. Why can I not just create a new graphic file from within my text document?

Lets look at a listing of common applications found in productivity suites and I think you'll start to see some overlap and similarities here:

Microsoft Office
Open Office
iWork / iLife
Word Processing
Document Publishing


Image Manipulation


Note Taking


Task Management

When you get down to it, in each category there are really only two types of applications. First, we have our layout oriented applications. Word processing, document publishing, presentations, image manipulation, email, note taking and diagrams are all examples of this type of application. You start out with a blank 'canvas', add in elements of text, images, lines, shapes, etc, and eventually you have a fully formed document.

Second are what I call 'cell' layouts. The idea with these is that you have discrete elements of data that you want to quantify and classify. Spreadsheets, task management and database applications all fall into this category.

Making it all Better

Because they have the most robust office quite, I am going to use Microsoft Office as an example of how I would go about leveraging the technology that already exists within their company to invent the office suite of the future. Its not that the other suites don't have the same problems (or problems of equal or greater stature), but most of us are more familiar with it than the other suites available in the marketplace.

The first change I would make is to ditch the separate applications and create a single base application framework. Instead of opening up each different application to do a specific function, the user would now open up Office. From there, the system would prompt if they want to open an existing file or create a new one from a set of templates. If the user selects the template option, they would then be presented with several different options which roughly corresponds to the individual applications of previous Office products.

Depending upon which type of document the user is working on, the Ribbon interface would display or hide specific sections. If the open document is just doing word processing, then the sections that correspond to Word would be displayed. If the open document is a set of data residing in the file system, then the Excel tabs would be displayed. If the open document is word processing, but has embedded table layouts, then the displayed sections would be a combination of both Word and Excel tabs.

My next change would be to the file structure itself. No more do we have .docx, .xlsx and the various different formats by application, but we have a single, unified file format. This .offx file is nothing more than a zip file with the existing file formats embedded and linked within it. This would not only save all of us hard drive space, but would allow for easier movement of files between different sources. This way, if you have a movie file linked to a document, when one file moves, they both move.

Lastly, I would make three additional integration enhancements:
  • Enhanced document revisioning = Give me something akin to Apple's Time Machine, but within a document. I need to be able to run backwards and forwards through a document and see exactly how it changed and who made the changes.
  • Enhanced autosave = If you haven't tried Google docs, do so for this one feature. If you make one additional keystroke within a document, it is immediately saved. Never again do you need to worry about losing a document if the power goes out. Why this isn't implemented in non-web office suites is a complete mystery to me.
  • Collaboration = Office does allow for a limited amount of collaboration, something that Microsoft is currently enhancing, but it generally requires a centralized server to perform this work. Because all changes would be autosaved to the document, a specialized server is not really necessary for each editor to be instantly aware of changes another editor makes, in real time. This is another way in which Google Docs outpaces Microsoft's offering (although in all fairness, there is no real 'client' application with Google, its all server).
That leaves us with the problem of default settings. From a technical standpoint, this would be easy to change, but I feel it is honestly the more difficult problem to fix, namely because most people don't see it as a problem. Sure, they may not be pleased with the limitations enforced by an 8.5x11 piece of paper, but have they ever really thought about why those limitations are even there? I cannot tell you how many of my customers and even how many of my managers have been tied to a physical piece of paper and liked it; couldn't get enough of it. For our tools to truly improve and mature, this mentality must go.

13 January 2010

BA tools stink, part 1

Ted Hardy, MBA, CBAP, is starting his ninth year as a BA and his third as a BA manager. He has worked around the globe for companies and clients in the high tech, finance and service industries. He specializes in business process analysis and communicating the impact of technology to his customers.

This is part 1 in a 2 part series. Part 2 will be posted tomorrow, so check back then for the conclusion.

One of the best things about being part of a BA community is how the thoughts of other BAs can spark a new line of thinking for yourself. You open up a link written by someone who you think highly about, read through the text, browse the diagrams and then somewhere near the bottom you have to stop reading to work through your own miniature brainstorm. Something the author wrote perked up a dormant neuron, just like that morning cup of tea perks you up. The same thing recently happened to me as I read Three Reasons to Upgrade from Business Rules to Decision Models by Barbara von Halle and Larry Goldberg.

The most intriguing thing to me was how they, unknowingly, captured one of my biggest complaints about the tools BAs have at their disposal for properly documenting process, procedures and requirements. The authors did a fabulous job making the case for why we should consider moving to decision models, but it only emphasized more that the tools to pull off such a change in focus simply do not exist.

Ways in Which Our Tools Fail

That is not to say that there are no quality tools out there for a BA to use, far from it. There are numerous tools to capture requirements and their attributes, to help map business processes, to capture sign-off from stakeholders and design prototypes or early mockups. Each of these tools is usually specialized for a single task, which is not a bad thing, but the failure of each of these tools comes in one of two stages.

The first failure is that of integration. Lets assume that our organization creates minimally functional prototypes whenever its time to do a system upgrade. We bring out our prototyping tool, create a few screens, add the needed fields, text and graphics, possibly throw in a little screenflow magic and tada, we have our prototype. Our stakeholders review that, possibly in a JAD session, give feedback which becomes a refined prototype and eventually makes its way into some type of requirements document.

Now, we have this great prototype that we need to reference in our requirements document. We've got a few options:
  • Screenshot = The most expedient solution is also the most destructive. All of the wonderful interaction captured within that prototype is gone in favor of something that can be printed out to be marked up by our stakeholders. The interaction can be marginally retained by adding in a series of shots or by placing navigation trails on top of the screenshots, but the 'flavor' of using the prototype just isn't there.
  • Video = This gives the stakeholder a better understanding of system usage, but still does not allow the stakeholder to actually use the application. They can see someone else use the prototype, but do not have their own first person viewpoint. While its easy to mark up a screenshot, its very difficult to do that with a video. You can't print it out like you could a screenshot, so while this solution gains something in terms of what the end goal is, it lacks considerably in terms of usability as a medium for capturing quality feedback.
  • Link = If that prototype can be bundled into a single executable file, or is something that can be served up as a web page, the requirements document can contain a link to the prototype that the stakeholder can use to launch the application. If the prototype can not be run without specialized tools installed or the application cannot be run from outside of a secured environment, then this is not a viable option.
The problem with each of these is that the requirements themselves don't have a good way to tie to the work that helped to drive out the requirements. There is no tightly-coupled link between the two different types of information.  There have been a few different specialized tools created to perform prototyping that include documentation within the tools, but they are generally expensive for an organization to acquire, require training and are not something that a non-technical stakeholder is going to understand without the BA there holding their had.

The second way in which existing tools fail is really an outgrowth of our society, with the focus on the printed page. The page formats we use (be they US Letter, A3, A4, Legal, whatever) are all based upon our trained desire to hold, touch and experience a physical representation of whatever information we are consuming. Gradually our society is changing, but the printed page still skews our sense of what is correct usage.

Why, in our digital age, is the 8.5"x11" page format the default setting in the US for word processing documents? The Google Doc I am using to write this is formatted this way, even though I will never ever print this document. While many people do print their documents, due to cost and environmental concerns, you will see less and less printing as the years go by and new professionals enter the business place that are more comfortable working with electronic media that physical media. Once the tipping point is reached where it is no longer the default mode to print, I am willing to bet that our document processing tools will still default to printed paper sizes. To me, this is absurd. Don't believe me? Take a look at this document I'm writing:

Sure, I could zoom in so that those large gray sections on either side of the screen are filled with text, but then I could see only a very small vertical slice of my document. I'm not saying its a better solution to have the text to remain the same size yet go from margin to margin as that would make the document very difficult to read. But this does illustrate that none of the paradigms we have inherited really fit with our current situation.

11 January 2010

Learning Project Management

Pawel Brodzinski has been blogging at his blog "Software Project Management" for several years.  He's generously agreed to write some posts here at Better Projects.  Here is the first.

This question hits me regularly from time to time: “Where one can learn about project management?


The most natural answer would be pointing some books but until you know whole background it’s hard to choose something suitable. You won’t advise book about Scrum for someone working in highly-formalized corporation employing Prince-2. Usually I choose safe way and point to Scott Berkun’s Making Things Happen which should work for everyone. At least significant parts, if not whole book, should.

The problem with books is you often can’t get specific answers relevant to your situation. You know, answers for questions like “We’re doing this and that and would like to go there – anyone went that path before and is willing to share the story?


There’s a site I recently fell in love with which helps here. AskAboutProjects goes on famous StackOverflow engine and is all about projects. You can ask every, even the most basic question, and it will be answered almost for sure. You don’t even need to register but you probably will to use awesome reputation system. Why not some forum on one of PM-related sites you ask? Well, the short answer is classic forums suck. Usability is a nightmare and there’s virtually no support to promote good answers over mediocre ones. Oh, just go check AskAboutProjects, you’ll get what I’m talking about in a minute.

PM Clinic

Another knowledge exchange place which I value very high is PM Clinic. This is totally old-school tool – a mailing list. What keeps me there is probably highest signal-to-noise ratio around and some very experienced people sharing their knowledge. If you look for basics that’s not the best place to go, but if know what this whole project management thing is all about and you’d like to get some from-the-trenches expertise PM Clinic is your destination.


There are blogs too – you’re reading one, right? Blogs share the problem of books a bit – you land wherever author wants to drive you. I won’t put here list of my favorites – you can check them in links section on my blog. You should do the same with other bloggers you respect and then find those who you like.


And there’s of course Twitter which I left for the end. That’s a complete opposite to PM Clinic: signal-to-noise ratio is very low. That doesn’t mean there’s no value in Twitter. You just have to learn how to judge quickly what is worth clicking and what is not. Otherwise you’d be wasting tons of time on Twitter. The great thing about Twitter is a surprise factor – you’ll find from time to time a real gem in the stream which you wouldn’t find otherwise because you wouldn’t know you should ask about it.

That works for me when it comes to looking for project management knowledge. How about you?

10 January 2010

Hello 2010

This is my first actual post of the new year. (The others were scheduled late last year.) In the next few weeks you'll be seeing a bunch of new Better Projects bloggers posting here. I am personally looking forward to some fresh ideas and perspectives.

Please take the time to offer comment when you see a new byline at the bottom of a post. Blogging is all about conversation, and it takes more than one person to have one, right?

5 January 2010

Use Cases and User Stories

Here is the last (for now) slide deck on Use Cases.

I am interested to hear your thoughts - do you use Use Cases? Do you see any particular strenghts or weaknesses in them as tools?

When should you and shouldn't you pull them out of your tool box?

2 January 2010


"Rework, retesting and refurbishing are not separate Work Breakdown Structure (WBS elements. They should be treated as part of the appropriate WBS element affected."

I can't remember where this phrase came from.  It was in a notebook of mine.  It may or may not be a quote but it is an appropiate sentiment towards the WBS.

In good practice project management this is what you do. In fact there are so many bad practices around the WBS it's worth spending some time on it.

When was the last time you inspect a manual on how to create a WBS?

Picture shareed by robpurdie CC at Flickr