How to Stay Relevant in Chaotic Situations

Do you work in a chaotic environment? Are you wondering how to make your business analysis skills relevant when you find yourself dismayed by how work actually gets done in your organization? Do you find your big projects continually blind-sided because everyone else is working on something else that’s more urgent, important, or critical than the high-priority project that needs your business analysis process?

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).  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. 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.

>>Stay Relevant

The most important thing in any job situation (at least for a job you want to keep) is that you apply the skills you have in a way that adds value to the organization. Click one of the links below to check out our other articles on this topic:

How Does Business Analysis Create Value?

What To Do When You Are In Between Projects: 10 Ideas That Add Value to Your Organization

Next Generation Business Analysts – The Opportunities In Store For You

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. Hi Mark,
    Thanks for unearthing this post for me. It’s been awhile and I had to refresh my memory about what I wrote. I like the action verb idea for helping wrap scope around a project and helping everyone get on the same page about what’s in vs. out. One of the challenges I face in more chaotic environments is confusion about “what project is that request in?”. Because there tend to be a lot of concurrent projects and shuffling of projects as resources become available or design decisions reveal unexpected overlaps in work, it can be a challenge to just remember what request goes where. Verbs might be a way out of that.

    This sentence stands out to me: “Part of the danger of chaotic environments is they often take shortcuts without realizing it.”

    I think this is so true. When you are focused on the end game and the world around you is amok, it is easy to take a short-cut through the requirements.

    I also agree that the BA can often bring order to a chaotic environment. I often feel a bit like a sage asking the basic questions….what did we put into the requirements, how are they realized into design, what requirement is that bug for? Sometimes introducing these sort of structured conversations can have a calming affect on a team.

    Laura

  2. Mark Jenkins says

    My approach, and the approach I now take with my analysts, is to first develop a complete, but very high level view of the project. This typically takes the form of what I would call “Power Verbs”. These are the action points that you can then use to maintain your sense of the project. For example if the “project” was to move house. The power verbs might be Investigate, Decide, Prepare, Pack, Move, Unpack, Recover.
    As I go through a chaotic project, I make sure that no matter what we do, we at least have done something in those key areas. This can help to ensure that when you get to the end of your move house project, you don’t find you have left your pets at your last place!
    Translating this to practical, chaotic projects or environments, we spend time at the start of each project to blow out each power verb into a series of action areas. These action areas, on which we would brainstorm to complete, then allow the BA to ensure that, regardless of the process being followed, the project will at least cover the areas it needs to. Part of the danger of chaotic environments is they often take shortcuts without realizing. This method ensures that if a shortcut is taken, you can gain at least a sense of the risk or what you won’t cover. One added advantage is that this technique often allows the BA to bring order to a chaotic environment. By being organized and disciplined, the BA is often able to help bring the project team or the department into some kind of structured organization.

  3. 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

  4. steve blais says

    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.

  5. 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,

    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.

  7. steve blais says

    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.

  8. 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

  9. 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.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.