Managing chaotic situations by building “the list”

by Laura (Brandau) Brandenburg on November 18, 2009 · 8 comments

in Communication, Managing Technology

I’ve been receiving a lot of emails lately asking for my help from business analysts in rather chaotic environments. Sometimes these BAs have good formal training, so they know how things *should* work and are dismayed at how things actually work in their organization. Oftentimes they shoot down the path of their first project with blinders on as to what else is happening in the organization. Then they have trouble obtaining input from stakeholders and implementers as everyone but them seems to be working on “something else”.

I have a slightly different perspective. I grew up building technology in relative chaos and then learned about process and then I saw some over-engineered processes that made the situation worse (and even tried to build a few of them). (Check out this post on jumping off that Ivory Tower.) I now find myself seeking a balance between process and achieving results, always on the hunt for “just enough” process.

But the question remains. When you enter a situation that is barely managed or completely un-managed chaos, or where deep organizational changes keep chaos looming over your head, where do you start? In my experience, the most valuable first thing you can do as a business analyst or project manager is build “the list”.

What is the list? Some people might call this the project list, the bug list, the maintenance list. Agile practioners will call it the product backlog. It really doesn’t matter what you call it or what tool you use, the purpose of the list is to get a full view of all the outstanding requests from all the possible stakeholders in the organization. This needs to include projects, bugs, half-finished features that a developer has already promised to a stakeholder, UI changes, customer updates, and the executive’s pet projects.

Much like the list of stakeholder requests within a specific project, this list should identify the business requester and a description of each item. You might start to classify the list into bugs, enhancements, and projects. As you groom the list, it becomes important to ascertain the potential business value to be achieved through each item as well as the overall effort required to implement it.

If you’ve been brought in to help with specific projects, you might need to start work on the list in tandem with more detailed work on the top priority project. It’s OK to swap back and forth between portfolio activities and project activities, as long as you can keep your head straight. You might even find that items on the list fit in nicely with the project you are working on, thereby condensing and streamlining the list a bit.

I’d be interested in hearing your views on establishing some order in an otherwise chaotic situation. What constitutes the first step toward managed chaos? How do you remove your blinders?

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

  1. Using a stakeholder requests list as part of scope definition
  2. Using an Issues List to drive software requirements to completion
  3. Building a better business analysis practice

{ 1 trackback }

Tweets that mention Managing chaotic situations by building “the list” -- Topsy.com
November 18, 2009 at 8:07 am

{ 7 comments… read them below or add one }

1 Adriana Beal November 18, 2009 at 11:04 am

Hah! Laura, I’m afraid I don’t have much to add here. “I grew up building technology in relative chaos” and “always on the hunt for ‘just enough’ process” pretty much describe my professional life as well :-) .

“The list” is my modus operandi too. Mine roughly follows the principles from David Allen’s GTD (http://en.wikipedia.org/wiki/Getting_Things_Done). I tend to use sticky notes to be able to move items from the “Next actions” list to the “Waiting for” list when an action has been delegated or is waiting for some external event, and vice-versa. Since I typically work in multiple projects simultaneously, I use different post-it colors to identify each project on these lists.

My lists provides not only the full view of all the outstanding requests from all stakeholders, like you said, but also UI changes that I want to propose given my own understanding of what might work best for the end user, identified conflicts in requirements that I’m waiting to address with stakeholders at the appropriate time, and any other thing I need to track, remember, or take action on.

I recommend trying the GTD approach to anyone dealing with a chaotic situation. It is an effective way of gaining control and perspective on your tasks, projects and priorities.

2 Laura (Brandau) Brandenburg November 19, 2009 at 8:22 am

Hi Adriana,

It’s always nice to have a bit of confirmation as to how other people handle this similar situations. Thank you. I am a big fan of David Allen’s Getting it Done book as well. I think you well illustrate how to apply it directly to BA work, which I have not done quite so well as I probably could be. Thanks!

Laura

3 steve blais November 20, 2009 at 5:46 am

I think everyone has some form of list that frames their working and social lives: lists of birthdays, special events, groceries to buy, things to do, etc.
The difficulty with the lists, and why they don’t work as well as they might for everyone is two-fold: prioritization, and as Laura mentioned, the “grooming”.
Lists typically fail by not adhering to Stephen Covey’s quadrants made up of Important and Urgent (or any other consistent form of prioritization). While this is a rationale way of handling lists it usually fails due to emotional implications. Yes, it is more important and urgent to get that report done for the Committee and a favored co-worker’s request is also somewhat important. Rationally we know the Committee report should be done first, but emotionally we want to help out our friend. Besides, the job for the co-worker is easier and can be dispatched more quickly and that gets one of those pesky TODO’s off the list and brings about that great emotional feeling of completion.
Grooming is equally important and is not simply prioritizing and re-prioritizing. According to the rationale time experts entries on the TODO list should be of equal work effort and take approximately the same amount of time to complete. This is the same principle as WBS. The “grooming” is the constant review and revising of the list to break some tasks down to smaller activities and to combine some small tasks for efficiency. Most people find that larger, more complex, more time consuming tasks on their lists are put off more easily because expected interruptions will break the flow of completing that task, so they do the smaller, shorter duration tasks – like straightening the desk, sharpening the pencils, or checking email – instead. Again, the emotional payback of removing tasks from the list comes into play.
Lists are natural and necessary to make progress, or at least give the appearance that progress is being made. The problem is in the manipulation of the lists once they are created. And the subtle evil – spending more time rearranging, re-priotizing and re-grooming the lists to increase the emotional payback of crossing something off the list. This includes adding something to the list – something that perhaps has already been accomplished – just so you can move it to the Done side. The over-riding danger: instead of manipulating the lists to make our lives more productive and efficient, the lists start manipulating us.

4 Adriana Beal November 22, 2009 at 3:42 pm

Steve,

I think that the main reason lists don’t work for some people is because the list owners are not associating the lists with some sort of system to help them control the various aspects of their work and keep the optimum focus for themselves.

When we find a system that works for us, adding something already accomplished to the list just for the “emotional payback”, as you mentioned, should quickly lose its appeal. I find my list-based method extremely useful to make sure that nothing of consequence is slipping through a crack, even when conditions change. A method like GTD is helpful because it goes beyond just keeping lists, allowing 20,000 feet, project-level, and action-level thinking.

5 Laura (Brandau) Brandenburg November 22, 2009 at 3:55 pm

Interesting perspective, Steve. I tend to tackle big projects by breaking them up…yes this is the grooming aspect. Sometimes it can be helpful to identify the “next action” (something I also learned from Getting it Done) and add that to your “to dos” so you can make noticeable progress against a big hairy item. But this is more for how I handle my own list of stuff to do. It’s a different, though similar, process when you are talking about a list of projects and enhancements that will be prioritized and delivered by multiple stakeholders. What you describe is what I typically think of as the requirements process for software! :-)

Laura

6 steve blais November 23, 2009 at 3:12 am

I certainly am not arguing against keeping lists. I have many and occasionally during hectic times, lists of lists. I was bringing up a few cautions about personal list keeping, most of which have tripped me up from time to time.
Due to their dynamics, development teams using product backlogs (lists) or burn down lists do not usually manipulate the lists. The public aspect of such lists is also a deterrent to gaming. What does happen is that the team becomes so driven by the list that the overall product deliverable – usually months away – gets lost in the monthly sprints and daily scrums. Team forget that the lists are the decomposition of a larger objective and get lost in the details. Because the team is focused on the next sprint, they lose sight of the big picture.
This is not an argument against the process. I know of no other approach to software development – or anything else – more simple and elegant. Because of that there is a natural human tendency to give power to the process. When the team spends an additional twenty minutes in a stand-up meeting debating the priority of three items on the sprint list, all of which are going to be accomplished in the current sprint, we can see how the list starts becoming more important than the results. Another example is when there is an extensive and heated discussion about the wording, not the intent, of an entry on a list. Of course, there could be another explanation. Since the process is so simple and elegant, we nerds as part of our nature need something to argue about, so we might as well debate the lists themselves.

7 Laura (Brandau) Brandenburg November 23, 2009 at 8:04 am

Hi Steve,
I couldn’t agree more. I’ve regrettably discovered myself debating something that is meaningless in the larger context on occasion and always feel a bit guilty afterward. It can be easy to get caught up in what you want you are doing and lose sight of what you want to achieve. I actually think what you describe is one of the most difficult aspects of being an Agile Business Analyst. In this role, you’ve got to keep your brain firmly planted on both sides — part in the big picture and part in the sprint-level execution against the big picture. I’d be interested to hear about tools and techniques that help balance both of these perspectives.

Laura

Leave a Comment

Previous post: What to focus on in a wireframe

Next post: Building a transition plan to onboard a new business analyst hire