At the end of the project, while our colleagues may have fond memories of the great work that was accomplished, what is left of the Analyst’s contribution is what was written down. Four releases from now, no one will be able to remember the awesome story planning session that led the team to the amazing backlog. All that is left is the set of user stories on the board. No one will remember the complicated effort it took to build the use case model; they will only be able to see what the use case flows tell us about the functional requirements for the system. And, trust me, if any of those flows have grammar or spelling errors, we leave the impression that we are sloppy. And if we are sloppy on this, we must have been just as sloppy putting together the use case model! Nothing can derail a requirements review like a discussion about the grammar used in the artifacts. You will quickly lose focus on the goal of the review and waste vast amounts of time.

I know Analysts who are amazing facilitators and terrible writers. I know Analysts who are terrible facilitators and amazing writers. In my hiring process, I need to be able to identify the Analysts who can do both. Usually, I can gauge a candidate’s face-to-face, facilitation and verbal presentation skills during an interview. To help me understand where a candidate is on the writing side, I request a writing sample. When I read that sample, I look at it from the perspective of my sixth grade teacher, Sister Theresa Clare. Here are some things she would tell me: “Does a comma belong there?”  “Does that verb agree with that subject?”  “Is that the proper use of ‘there’ instead of ‘their’?” Clearly, automatic spell checkers have turned your brain to mush!”  (Okay, she didn’t tell me that. We didn’t have automatic spell checkers when I was in sixth grade. You get the point…)

I know, I know, “What’s your point? You want me to write like a sixth grader?” If that’s what it takes to make you a good writer, yes! Actually, what I want is for Analysts to pay attention. The words on the page shape the solution, and yes, the correct placement of commas can make a difference in that solution. Remember that bad writing leads to bad requirements and bad requirements lead to bad solutions. Who wants that? If you feel like you need a refresher on sixth-grade grammar, try Eats, Shoots & Leaves: The Zero Tolerance Approach to Punctuation. And of course, there is always my favorite exercise: Add punctuation to this string of words: “woman without her man is nothing.” See how different punctuation creates different meaning?

SOUND OFF: Have you had enough of poorly written requirements? Tell us about it. (Oh yeah, and we can help with that…)

Over the years, having been on multiple projects, I have captured many quotes from each and every one. Some original, some not, but all meaningful in their own way. So, for this blog post, I perused through the extensive material in my quote books and pulled 10 memorable ones pertaining to analysis, many of which could pertain to providing professional services in general as well, I suppose.

1. “Seek first to understand before being understood.”
2. “Knowledge speaks, wisdom listens.” ~ Jimi Hendrix
3. “Clarity is key.”
4. “In terms of asking questions, I plead guilty. I ask a heck of a lot of questions. That’s my job.” ~ Dick Cheney
5. “Easy reading is damn hard writing.” ~ Hawthorne
6. “Always remember your audience and setting.”
7. “Personal relationships are the fertile soil from which advancement, success, and achievement in real life grows.” ~ Ben Stein
8. “Nothing great can come without enthusiasm.” ~ Emerson
9. “Be curious, not judgmental.” ~ Whitman
10. “Everyone has a plan until they get punched in the face.” ~ Mike Tyson

SOUND OFF: Do you have any memorable quotes you keep in your repertoire?

Using these techniques allows BAs to:

• Give sponsors and stakeholders a straightforward, easily understood view of their business processes;
• Provide meaningful information that will aid customers with achieving their objectives;
• Furnish members of the project team and others with their roles, tasks, and levels of responsibility.

An added benefit is the information generated by these techniques is valuable whether the customer is using a traditional or an agile lifecycle.

1. State Diagrams

Humans are visual learners and State Diagrams (sometimes called Process Models) provide an excellent method of giving sponsors and stakeholders easily digestible views of their company’s business processes. Horizontal swim lanes help team members visualize processes as they flow between the responsibilities of different actors.

To make them easier to understand, keep state diagrams at a high level of abstraction and don’t inject too much complexity into them all at once. Complexity should be accumulative as the reader begins with the highest level process and then drills down through successive parent and child processes.

As presented in the order flow state diagram below, a customer places an order with the call center and the order is shown moving out of the call center and into different stations within the warehouse. Off-page connectors are used to point readers to other state diagrams that provide greater detail for each of those process threads.

Why are State Diagrams a killer technique? Being able to easily visualize current and future processes enables customers to better express their needs and that ability translates into better requirements. This format can also be referred to by cross-functional teams throughout the life of the project to ensure everyone remains in agreement with the stated objective,

2. SWOT

This venerable, widely-used technique focuses on factors governing the operation of most companies: Strengths, weaknesses, opportunities, and threats. SWOT is typically employed during enterprise-level initiatives such as strategic planning, evaluation of competitors, product development, and so on.  In this context, SWOT is a powerful analytical tool that’s used during group brainstorming activities because it emphasizes prospects and problems from four different perspectives internal and external to a company:

Internal

• Strengths
  • What does the company do well?
  • What advantages does the company hold over its competitors?
• Weaknesses
  • What can be done better to increase the company’s market share?
  • What problems can the company avoid?

External

• Opportunities
  • What new developments in the market benefit the company?
  • What new technologies can the company implement to increase market share?
• Threats
  • What obstacles stand in the company’s way?
  • Are changes in the market, technology, or other issues threatening the company’s position?

In another context, SWOT can also be used by the Business Analyst to capture notes from each of the four perspectives. In any meeting where crucial issues are being discussed, include the appropriate content beneath the S, W, O, or T classifications. By grouping notes in this manner, Business Analysts can derive a greater understanding of the problem under discussion.

Why is SWOT a killer technique? SWOT focuses on concrete internal and external factors that aid or prevent a company from achieving its objectives. And this is true regardless of whether a SWOT analysis is being applied to a company, a product (new or existing), or a competitor because it delivers meaningful information that helps to ensure a better strategic fit that matches the customer’s future goals.

3. RACI

Typically used by Business Analysts and Project Managers during stakeholder analysis, the RACI table acts as a responsibility assignment matrix which identifies the association between a project’s tasks (on the vertical axis) and its roles (on the horizontal axis).

As demonstrated by the diagram below, each task is given a unique number and name down the right side of the RACI matrix and project roles are defined along the top. The intersecting cells define the level of responsibility a role has for a specific task.

The RACI participation types are defined as:

• Responsible: A single person (or possibly a team) that’s on-the-hook for getting work accomplished. There should always be at least one role with a participation type of responsible;
• Accountable: This role is answerable for the project’s overall success and must ensure the completed deliverable is correct;
• Consulted: These are typically SMEs (Subject Matter Experts) who are sought out by team members because of their high level of expertise in specific areas related to the project;
• Informed: These roles can be filled by those who need to be kept up-to-date on the progress of tasks and deliverables or individuals or groups that have some dependency on the completion of a task.

Why is RACI a killer technique? The RACI responsibility assignment matrix holds Stakeholders accountable for their assigned project participation roles. It also continues to remind Stakeholders of their roles throughout the life of the project and can be referenced should confusion or disagreements occur over roles or assignments.

Conclusion

Business Analysts are always expected to deliver accurate information in a timely manner to their sponsors and stakeholders. But much of the time, BAs are buried beneath the weight of so much information that it becomes a time-consuming task to provide meaningful content in an appropriate context to different consumers. This is further complicated when moving between traditional and agile life-cycles where each approach places its own unique spin on project deliverables.

The techniques described in this article give the Business Analyst three powerful methods of delivering meaningful information that will be useful to project sponsors and stakeholders regardless of the life-cycle methodology in use.

SOUND OFF:  What killer techniques are in your analyst’s toolbox? Are there any variations of the techniques described in this article or in the BABoK? We’d love to hear from you!

Imagine this. You set out to redo your old kitchen cabinets. Grand undertaking that will look absolutely great when finished. You measure the space throughout your kitchen, you pick out the cabinets, hardware, etc., you hire a contractor to install them, and when finished, guess what? They look absolutely great! Only one problem: they do not fit your everyday needs. The tall glasses you were given as a gift do not fit anywhere because the height between the shelves is not enough in any of the cabinets. The Tupperware you use on a daily basis fall out of the shelf every time you open the door because the cabinet you have to put them in is not deep enough. To set the table, you need to go to three different places because you could not put the plates, the glasses, and your silverware in close proximity to each other. You get the point. The cabinets, however, look great and all your friends cannot stop complimenting you about them.

What went wrong? What you should have done differently? In an overly simplistic way, let me offer you this: first, you should take an inventory of what you need to store. Second, you should observe and note down how you use your cabinets on a daily basis. Third, you should also note down if you are planning on making changes to your everyday use of the cabinets. Notice I am saying to note these things down. It is not enough to think about them and keep them in your mind as you go about your project. There is value in seeing things on paper or on a screen (whatever your method of capturing information). Things look different and they are more real. Once you are done with these three steps, then you start designing to fit the needs you have identified. The rest of the steps are pretty much the same as before, and the end result is not only cabinets that look great but also cabinets that are functional for your way of living.

What does all this have to do with analysis in software development? The same principles apply. Would we jump in and build software without figuring out what is already there and what is really needed? Would we, instead, take the necessary time to understand the problem first, determine possible solutions, assess the risks and benefits of each, and plan everything out before we start building? Consider one more thing. Returning to the kitchen cabinets example, what if after having spent tens of thousands of dollars replacing the cabinets, you find out that the only thing the old cabinets needed was a fresh coat of varnish?

Next time you need to do a project, at home or at work, take the time to do the proper analysis before you jump into it. The results will be better and you will not have to rely on luck for them to turn out just okay. You will end up with what you really need and it will cost you a fraction of what it would have cost you had you not done your due diligence. It is worth it.

SOUND OFF: Have you suffered the consequences of inadequate up-front analysis in home or work projects?

–Isaac Newton

Have you ever attended a meeting hosted by a facilitator who was so good their presence faded into the background without anyone realizing it? I’ve always admired talented facilitators who expertly guide the participants in their meetings towards consensus and are all but invisible unless they’re needed to keep the discussion moving forward.

Although irrespective of how effortless some facilitators make it appear, good facilitation is all based on the hard work and careful preparation that occurs before, during, and after a meeting.

In an ideal world, meetings would end with participants all in agreement, but in practice that’s usually not the case. Although the closer we can come to achieving that ideal scenario, the better the result will be for our customers. Why? Because good facilitation promotes enthusiasm which helps to promote consensus, and consensus promotes a feeling of shared purpose and empowerment throughout an organization. But that goal can only be achieved by first bringing people together and empowering them to collaborate so they can reach consensus on a solution that benefits their entire organization.

I’ve studied the techniques of some very skilled facilitators, and this article includes what I regard as the critical elements that go into effective meeting facilitation.

Before the Meeting

As much—if not more —time and effort can go into planning a meeting than actually facilitating the meeting itself. Without adequate preparation, any meeting can quickly dissolve into a chaotic mess. The items below will help to answer the question good facilitators always ask themselves prior to each meeting: “Am I ready?”

• Establish meeting boundaries. Building fences around a meeting is accomplished by creating an agenda that includes the meetings start and stop times, a problem statement, the goal, and any expectations you may have of the participants prior to their arrival at the meeting. It’s important to understand that in order for a meeting to be effective, it must first have a structure. An agenda also gives participants a chance to think about the upcoming discussion so they can effectively organize their thoughts ahead of time.
• Know the participants. Find out who needs to attend the meeting and touch base with any key players to obtain their perspectives on the problem. Be aware of any departmental or interpersonal conflicts, and be prepared to use your negotiation skills to bring those parties into agreement.
• Be able to provide a clear and concise description of the problem. Take the time necessary to fully understand not only the problem, but its overall impact on the customer as well.
• Prepare the meeting space. If the meeting is held in a conference room, ensure enough chairs are available and there are dry erase markers and an eraser for the whiteboard (assuming there is a whiteboard). If using a laptop and overhead projector or flat screen display, test all of the connections prior to the meeting as well as verifying the laptop has access to all of the necessary files needed during the meeting. If some participants are attending via teleconference, then ensure they have the correct dial-in numbers and pass codes.
• Assemble any necessary documents. Make sure any documents that are needed or might be referenced during the meeting are available and ready for use. In my analysis discipline library I keep templates for capturing action items, parking lot items, and meeting minutes. I normally move these templates to a public SharePoint folder (assuming one exists) and rename them so they’re easily accessible by all of the meeting participants.

During the Meeting

Now that it’s begun, there are a number of elements that must be taken into consideration and managed throughout the meeting.

• Assign someone to record the meeting minutes. It’s difficult to be a facilitator and to also record the minutes as well, so ask for a volunteer from among the participants and if no one volunteers, then pick someone.
• Stay neutral and maintain objectivity. Taking sides or injecting yourself into the discussion is never an option.
• Ask more questions than you answer. You’re not there to advance one solution over another or to insert your opinions into the discussion.
• Use active listening. Stay in the moment and listen closely to what the meeting participants are saying and be prepared to offer constructive feedback if, for example, someone has difficulty articulating a concept or idea or if you need to re-state a salient point brought up during the meeting.
• Keep the discussion balanced. There are two discrete types of processes associated with creative and critical thought. They are called divergent (creative) and convergent (critical). If the meeting becomes too divergent, then participants will be overwhelmed by the number of ideas or too many possible solutions. If the meeting becomes too convergent, the exact opposite occurs: ideas are rejected too quickly or not voiced at all, and participants are left with limited choices. In order for a meeting to be truly effective, a balance must be struck between these two processes.
• Ensure that everyone participates in the meeting. It’s important to nurture a safe, positive environment and to encourage collaborative behavior among the participants. So if you see someone who isn’t contributing to the conversation, then find an opportunity to solicit their comments or to ask them a question. Sometimes a simple “What do you think…?” can draw someone out of his or her shell who can make an important contribution to the discussion. Delivering an agenda prior to the meeting also helps introverts with understanding the problem ahead of time so they’re better prepared to join in the discussion and to feel much less awkward if called upon to speak.
• Don’t let anyone hijack the meeting. Some participants may want to use the meeting as a soapbox for something they feel passionate about. So be prepared to enforce the meeting’s boundaries if the conversation starts to head off in a divergent direction. A technique I often use to push back on participants who keep pushing a meeting off-topic is to firmly remind them of its boundaries and to let them know their concerns are being captured as “parking lot” items that will be addressed after the meeting.
• Capture action items. As the meeting progresses, if actionable items pop up that need further work, then record them as action items. Consider using a spreadsheet to enter action items (and parking lot items as well), as that medium provides a common, reusable format that allows filtering by completion status or any other criteria the group may decide to use.
• Keep track of the time. As the meeting nears its end, halt the discussion to test for consensus to determine whether or not another meeting is needed. As a rule, I normally begin this final stage 10 minutes from the stop time because it usually takes 3-5 minutes to close out the discussion. If time permits, provide a brief summation of the meeting and reiterate any action and parking lot items that were captured during the meeting.

After the Meeting

Even though the meeting is over, the facilitator’s work still isn’t done. Executing the items below will ensure the successful completion of the meeting.

• Capture whiteboard content. Use a smart phone to take a photo of the white board so any processes or other information can be captured for future reference.
• Distribute the meeting minutes. Clean up and summarize the meeting minutes and email them—including a list of any action and parking lot items—to each of the participants as well as any other concerned parties.
• Follow up on actionable items.  A realistic timeline should be drawn up for completion of the action and parking lot items captured during the meeting. Be prepared to provide this information as well as each item’s completion status to any interested parties.

Conclusion

As you can see, successful meetings don’t occur by accident. They are conceived through sufficient preparation, effective facilitation, and appropriate follow up. Many people dislike meetings and feel they’re a waste of time due to their prior experience with poor facilitation. Implementing the critical elements of effective facilitation introduces structure and balance into a meeting and creates a collaborative spirit that promotes enthusiasm and encourages critical thinking. People leave well-facilitated meetings energized, thinking to themselves, “Now that wasn’t a waste of time!”

SOUND OFF: What other elements do you introduce before, during, or after your meetings to promote effective facilitation? We’d also like to hear from analysts who are or have been part of Agile projects. How has Agile changed the way your facilitate meetings?

1 – An Organized Requirements Repository is a Good Thing

Developers and testers do not like to read requirements—they’d rather spend their time testing and building the system. If requirement artifacts are difficult to find, your team members are even less likely to reference them. Organize your requirements in a centralized location so that all project team members and stakeholders can easily locate them.

SharePoint is widely used to manage project content, but organizations usually limit users’ access. Make sure all consumers of requirements already have, or can be granted, access to your repository.

2 – Not Reviewing Requirements with Testers Upfront is a Bad Thing

A good requirement does not leave room for interpretation. A good tester will ask questions about unclear requirements, which leads to more analysis work. Ultimately, this work will need to be completed, so you might as well do this upfront while you have business stakeholders’ time secured. Analysts and testers should have continuous, honest communication throughout the project.

3 – Requirements Can and Should be Tailored to the Audience

What good is a requirement if it doesn’t help a downstream customer understand what needs to be built? Often, it makes sense to represent requirements differently in order to effectively communicate them to various audiences. Again, no one enjoys reading requirements documents. Perhaps a flowchart would be more effective? Ask your downstream customers in what form they prefer to see requirements.

In producing different forms of requirements you will sharpen your analysis skills and also challenge your own understanding of what you are building. This will ultimately increase the quality of other requirements deliverables, no matter what form they are in.

4 – Poor Change Management = Poor Tests = Missed Requirements

Change happens—this is inevitable. Projects should always follow a documented, clear change management plan. If an organization has an existing change management plan, follow it. If not, create one. You don’t have to go crazy here, just make sure you get buy-in from all project team members and that everyone understands it. The change management plan should include a step to modify test cases as requirements change. If you do not have to revise test cases during your project, you’re probably not following a change management plan, and you’re going to miss some requirements.

5 – Requirements and Features Should be Prioritized by Stakeholders

Every project has deadlines. You will inevitably find that some tasks will take longer than expected and some things will prove to be more complex than they seemed when time estimates were completed. Ideally, an analyst should get stakeholders to rank features in order of importance. This will enable a seasoned tester to focus on the most important features when time constraints occur.

Also, note how often certain features or workflows are used. This can assist testers and analysts in enhancing a site or application’s usability (for example—reducing the number of clicks it takes the user to perform a high frequency task).

6 – A Requirements Traceability Matrix (RTM) Adds a Lot of Value

The perfect place to capture rankings and frequency of use is in a requirements traceability matrix, or RTM. If done well, an RTM will make a tester’s job easier. It should categorize requirements, which will naturally translate to logical groups that can be used by the testing team. If there are multiple testers, the categories can be divided up among the testers, allowing each to focus on a specific area of the system or application. These categories will also come in handy when the testing schedule is created. Lastly, an RTM will help the tester ensure that all requirements are covered by their test plan.

SOUND OFF: Have you ever donned two different hats during a project? If so, what did one role teach you about the other?

So why do we have such hard time giving what we do a title? The reality is that we do so many things, it is difficult to pinpoint the one thing we do. My team consists of people who have experience as developers, DBAs, business-side. Some of us have been in professional services forever and others are new to the idea. Some have been corporate ladder climbers, others have owned their own businesses, many lived through Y2K and the dot-com bubble while others have only seen “punch cards” in the museum of computer science from long, long ago.

The common thread that holds us together is that we love digging in, rolling up our sleeves, and figuring it out.  We  relish in introducing ourselves to total strangers over the phone or email (or Instant Messenger or even Twitter!).  We find appreciation for everything we learn, whether that is a critical GxP business process, the topography of a cloud-based PaaS, or simply what happens to the content of safety deposit boxes that go unclaimed.  (It varies by State, according to what the regulations say you can do with it…) We are master negotiators, expert meeting facilitators, and know how to order catering for 5 to 500.  (Make sure to get chocolate for the afternoon!)  We work in tools, without tools, in tools that aren’t really tools. Whiteboards, storyboards, user story backlogs, defect logs, requirements logs—all are part of our landscape.

How do you summarize that in a title?  For now, I am sticking with Analyst.  Of course, this does sounds like something I should dig into, roll-up my sleeves, and figure out.  Anyone else up for the challenge?

Awesome at
Nailing it down
All while
Looking for ways to increase
Your productivity and
Still maintain
True balance

SOUND OFF: How do you define what a BA/SA/BSA does?

I recently had the opportunity to become acquainted with the Scott W. Ambler and Mark Lines book, “Disciplined Agile Delivery, A Practitioners Guide to Agile Software Delivery in the Enterprise,” which defines a robust process framework that extends the software construction life cycle to support enterprise solution delivery.

According to Ambler and Lines, some Agile practitioners feel that due to its focus on construction-oriented activities, the core Agile process framework isn’t mature enough to provide features crucial to the enterprise such as governance, architectural planning, modeling, auditing and regulatory compliance, and the support for larger, geographically distributed teams. In their introduction to Disciplined Agile Delivery (DAD), the authors describe how less mature Agile teams often lack the necessary discipline and process rigor needed to deliver for the enterprise because many times they dismiss those features as unnecessary. But as the title of this post indicates, DAD extends core Agile by incorporating it into a new, robust Agile process framework.

This post provides a simplified, high-level description of how the core Agile process framework has been extended to meet the challenge of delivering solutions for the enterprise. I would encourage anyone who wishes to learn more or who has already wrestled with tailoring core Agile methods to meet the demands of enterprise-level solution delivery to pick up a copy of this excellent book.

The Core Agile Process Framework

Agile software development (ASD) is a process that Wikipedia defines as, “…a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.”

To illustrate this definition, the diagram below provides a high-level overview of the Scrum process. It demonstrates how mainstream core Agile performs construction activities that are often described as value-driven life cycles where small, self-organizing teams produce customer-approved, straightforward code that’s frequently tested and delivered at the conclusion of each sprint (or iteration).

Extending Core Agile

As you can see, Scrum is not the only component that’s needed for the delivery of complex solutions and without significant customization; it doesn’t scale much beyond the software construction life cycle  So to overcome this obstacle and achieve the scalability and other features needed at the enterprise, Ambler and Lines extended Scrum by incorporating it into the DAD process framework.

Figure 2 below describes how some of the characteristics of core Agile were extended into the DAD process framework.

The Disciplined Agile Delivery Process Framework

Ambler and Lines define the DAD process framework as a “hybrid” that “…extends the Scrum construction life cycle to address the full delivery life cycle while adopting strategies from several Agile and lean methods.” They go on to describe a common pattern they’ve seen repeated in many organizations where Scrum or another Agile method is adopted and then it must be heavily tailored using strategies from a variety of different methods (i.e., Extreme Programming, Agile Modeling, and Unified Process). Their intent is the creation of a robust process framework that defines common tailoring strategies already being used at most organizations which have implemented Scrum or other Agile processes.

For those organizations that are using Agile processes, there are many benefits that come along with adopting the DAD process framework. These include teams being “enterprise aware,” meaning they function within the organization’s enterprise ecosystem so effective and appropriate governance can be performed. The framework offers a “risk and value-driven” characteristic where risks such as stakeholder consensus and architectural planning are addressed early in the life cycle  It is also scalable based on factors such as team size and geographical distribution, technical complexity, and regulatory compliance.

As demonstrated in the DAD process life cycle diagram below, we can see that Scrum has been extended to three phases: Planning, Construction, and Release. Each phase has three stages: Coordinate, Collaborate, and Conclude. Ambler and Lines call these three phase stages the “3C rhythm” and they map directly to the concepts of inception, construction, and transition, respectively.

Conclusion

Conventional Agile approaches such as Scrum or Extreme Programming only deliver part of what’s needed for complete IT solutions, while DAD provides a robust process framework that assembles common Agile methodologies and strategies and focuses them on a full delivery life cycle.

If you would like to learn more about the DAD process framework beyond the book referenced at the beginning of this article, there are a number of sources on the Internet including the Disciplined Agile Delivery website that is moderated by Mark Lines and Scott Ambler.

SOUND OFF: Have you ever had to tailor an Agile Scrum process to extend it beyond the software construction life cycle? What challenges did you face?

When I came on board, the project was in flight, over budget, and close to not being delivered on time. The customer was plagued by problems that seemed to come out of nowhere and as soon as one problem was shot down, another one would fly in to take its place. And being over budget, they were feeling the financial pinch, but this project was a critical component in their planned future growth so failure was not an option.

Strapping on my jet pack, I picked up my paint gun and flew to work!

Applying the Base Coat

Experience taught me that I had to quickly come to grips with the project’s current state. So once my approach received a green light from the Project Manager, the first order of business was to meet with each of the Business Analysts to gain their perspectives on what worked and what didn’t. I also needed to capture the current Requirements Management processes as well as evaluate BA work habits so I could deal with any experience or skill set issues.

Since the project was in flight, I shadowed the BAs for a day or so as they went about their assigned tasks in order to gauge how well information was being communicated by the BAs—the voice of the business—to other teams on the project.

Within the same time frame, I met with the Development and QA Leads as well as each of the Business SMEs involved in the project. I gathered their input on BA performance and deliverables, how business deliverables were approved and handed off, and their ideas on what improvements could be made.

In less than a week a picture emerged of an immature application-delivery infrastructure and a customer who had taken on a large, extremely complex project that required a level of sophistication they were ill-prepared for given the state of their requirements management processes as well as their overall delivery pipeline.

Listing the issues I’d uncovered, I identified and prioritized the issues we needed to correct ASAP if the project was going to have any chance of pulling out of its tailspin. Items at the top of my list included:

• Project Management had little or no visibility to “blockers” who were preventing the completion of assigned tasks. BAs would simply sit on a task until, for example, a needed resource became available.
• Reporting risks was hit and miss at best, so when risks turned into issues the project team was blindsided and problems would seem to appear out of nowhere.
• Meetings were poorly facilitated, sometimes chaotic, and many times the wrong audience was involved.
• BA deliverables always included low-level design and development information mixed in with business content. There wasn’t a clear understanding of where the BA work (i.e., the “what”) ended and Development work (i.e., the “how”) began. This confused and frustrated the Business SMEs because they didn’t know which kinds of content they were actually approving.
• No formal Change Management process existed, which contributed to serious scope creep. This helped to push the project over budget because work wasn’t being delivered on time.
• No formal Requirements Management Plan existed, but instead an in-house tribal process had evolved for pushing work through what often times was a very leaky pipe.

Applying the Top Coat

In order to realign the project’s requirements management practices to get them back in line with at least a minimum of industry standard practice, I saw three areas that needed immediate improvement:

• BA Communications
• BA Deliverable Content
• Requirements Management Practices

I had to carefully weigh the overall impact of inserting new process into an already dangerously overburdened project, especially in an environment that was highly resistant to change.

Too much change and the project would grind to a complete halt. Too little change and the project would continue to sputter and stall out.

Since I couldn’t undo the poor planning decisions that led to the situation the customer now found themselves in, as demonstrated by the table below, I opted for quick wins that would speed up the pipeline without seriously over-pressurizing it.

Conclusion

As you can see, the improvements described above aided in smoothing out the delivery of work, but they were just what their name implies: quick wins. There was still a lot of work left to do to correct critical issues throughout the entire application delivery infrastructure so future projects wouldn’t repeat the costly mistakes of their predecessor.

Change is always difficult. And while some organizations adapt to it without too much contention, others are more resistant to altering the way things have always been done. On this particular project, I received push-back from some team members who thought the changes were either too much process or a complete waste of time. But from many team members—particularly the embattled Business SMEs—there was a new perception that some order had been restored and the project had been pulled out of its tailspin.

And that’s how you paint a commercial jet at 30,000 feet.

SOUND OFF: Have you ever had to adjust the requirements management process for in in-flight project? What challenges did you encounter?

This post was prompted by a recent article from Nancy Nee on the Modern Analyst website “10 Key Business Analysis Trends For 2013,” where she predicts that in the year ahead, “modeling skills will take precedence in business analysis training.”

Nee goes on to say that, “Many organizations that have embraced Agile and business architecture are beginning to understand the importance of modeling skills and the value they bring in delivering quick, efficient solutions. Agile projects and effective business architecture both require a strong skill set in process and use case modeling. Modeling techniques will be a key focus area for BAs in 2013 as these tools will become critical in depicting the impact of solutions on the business. As such, the written word will continue to slowly lose its appeal and significance when describing solutions and impact to customers.”

I’ve since discovered that many of the activities I perform as a BA are also needed to develop Business Process Models as well. So in this post, I’ll first explain what Business Process Modeling is and why it’s important. Then I’ll describe how BPM ties into the core soft-skills that all BAs are familiar with.

What is BPM and why is it important?

A Business Process Model represents one or more structured processes performed by a business that directly or indirectly produces a product or service. The process model captures each activity and decision-point as a product or service travels along the path towards its completion and consumption by a human or non-human consumer. Process models place a strong emphasis on “how” work is done within the business rather than focusing on the “what” of an end-product the business produces.

Process models are normally diagrammatic (usually UML) and produced by sophisticated modeling applications such as Sparx Enterprise Architect. But they can just as easily be Visio diagrams or even post-it notes connected by marker on a whiteboard. And while theoretically, an entire business can be described by a single model, for process models to remain meaningful to people, larger and more complex processes are usually broken down into smaller, sub-process models that work together to describe the business as a whole.

The importance of BPM lies in its ROI to businesses. Process models provide the necessary current-state documentation that describes how all of a business’s processes work as well as the activities and actors which are involved with them from start to finish. Once complete, a “current state” model can be analyzed to realize efficiencies that eliminate redundant processes or needless complexity. This makes businesses more responsive to their customers as well as lowers their operating costs. For example, process models allow businesses to identify and automate repetitive manual processes, providing faster execution at less cost.

The Correlation of Core BA Skills to BPM

Like any professional discipline, BPM has its own well-documented standards and practices that govern how modeling is performed. But if we take a step back from the rigor of BPM as a discipline we can see, as illustrated by the image below, the connection between the methodology described for developing process models and the soft-skills used by BAs during requirements elaboration.

Image 1: BPM & Requirements Management

To demonstrate this point in more detail, the table below provides high-level correlations between BPM activities in the left column and Requirements Management activities in the right. As you will see, the same soft-skills you already possess can be leveraged to develop process models!

For businesses overloaded by needless bureaucratic exchanges, redundant or repetitive processes, or simply too much administrative expense, BPM is an extremely valuable planning asset. It allows businesses to streamline their processes thereby cutting costs while at the same time putting them on a firmer, better-understood path to their future growth.

As Business Analysts, we already have the necessary soft-skills for working with our customers to develop process models. Learning the hard-skills needed to produce process models in a modeling application is simply a matter of obtaining the appropriate training.

Now go forth and model!

But as project budgets and timeframes continue to shrink, analysts must also look for ways to shave time off their requirements gathering and elicitation activities because spending valuable time chasing down unnecessary information erodes an analyst’s ability to deliver their work on time and under budget.

One way analysts can utilize their time more effectively is to know when to put on the brakes and stop gathering requirements.

So When Does Done Really Mean “Done”?

A question that I’m frequently asked by customers and colleagues alike is, “How do we know when we’re done gathering requirements?”

To answer that question, there is a two-step process that we can use to first put on the brakes to stop the gathering process and then to evaluate our requirements against a set of completion criteria.

Putting on the Brakes

As you elicit requirements, remain cognizant of the number of new requirements or the amount of significant changes to existing requirements that you’re receiving from your SMEs and other knowledge resources. As the volume of both of these kinds of information decreases, start looking for any repetition (i.e. the same requirement being repeated differently) or information that doesn’t conform to business goals or that’s out of the project’s scope. When you begin seeing this type of “noise” during your elaboration, then it’s probably time to put on the brakes and stop gathering requirements.

Think of it this way: When you start gathering requirements, you’re drinking from the fully opened valve of a fire hose. But as your work progresses the valve is tightened down until finally all you’re left with is an unhelpful trickle.

But once you’ve stopped gathering requirements, how do you know if you’re really “done”?

Well, you won’t know that until the gathered requirements are given a reality check!

Validating Gathered Requirements

The following list of questions is a litmus test you can use to evaluate each requirement to ensure its accuracy and efficacy.

For every requirement, ask the question “Is it…”

• Complete – Does the requirement have missing information?
• Consistent – Is the requirement consistent with other sources of information (internal or external)?
• Correct – Does the requirement meet the business goal as well as fall within the given project scope?
• Necessary – Is the requirement needed or is it extraneous information (i.e. “noise”)?
• Traceable – Has the requirement been uniquely identified so it can be traced?
• Unambiguous – Does the requirement apply to only a single interpretation?
• Verifiable – Does the requirement meet with the approval of both business and downstream consumers?

Once all of the requirements have successfully passed the completion criteria above, then done really does mean “done.”

SOUND OFF: What’s the most important thing you do to ensure you deliver high quality requirements?

• When someone is trying to decide that the page exception they just uncovered in the app is a defect:  “You can’t be just a little-bit pregnant; of course it’s a defect.”
• When features need to be put on hold or completely eliminated from scope:  “Is this modified or full bed-rest?”
• When trying to decide if a particular change request needs extra funding:  “Will this be a natural labor or are we going to need an epidural?”
• And my favorite—when the project is spiraling out-of-control:  “Is this real labor or are we just having Braxton Hicks?”

So what does that have to do with requirements management, anyway?  As a requirements analyst, I take pride in understanding the audience I’m writing and presenting for and customizing my approach accordingly.  Even the IIBA views this particular skill as an attribute of  the Requirements Management and Communication compentency.  I do this in the “official” work I do, but how well do I this with the people I speak to everyday?  My point here is that I need to make sure the words I use, even in my day-to-day conversations, are understood by all of my team members.

Let’s be real though—not everyone is going to understand the references I list here.  And, I know, many of the terms my colleagues use are so deeply ingrained in their repertoire that asking them to change would cause a stir.  I’m not looking for that, only that we need to pay attention to the words and metaphors we use.

I know what you’re thinking: this isn’t going to fix the sports analogy problem.  I’m pretty sure I can’t fix that in a single blog post.  What I can do, though, is admit my confusion when I don’t understand analogies and metaphors and ask for clarification, and hope that will empower others on the team to do the same.  Ultimately, as a champion of clarity, isn’t that what I am supposed to do?  (And, of course, if I can do that without sending the Project to Triage to be monitored, all the better!)

SOUND OFF:  Are you tired of cryptic metaphors?  How do you make sure everyone on your team hears the same thing?

OK so here’s the thing, I always know when my grandfather is at the piano because he always starts and ends with the same songs -  that’s what is in his set list.  For the record, he closes with “Five-Foot Two”.   Prior to that we are treated to a variety of hits from the 40′s such as:

• Sweetheart of Sigma Chi
• Shine on Harvest Moon
• It Had To Be You
• Traumeri

His performance is effortless. He started playing when he was a young child, bought his first piano when he was 18, started a band, the “Hoosier Lucky 7″ (see the pic above, Gramps is the cool cat at the piano) and plays to this day. At 103 I don’t know anyone who has demonstrated more committment to their art. His song selections are always appropriate, he chooses the songs for the occasion and the length of time he has (or wants) to play. He uses his experience to guide his set list.

So what does this have to do with Requirements Management anyway?  One of the questions I pose to Analyst candidates during interviews is along the lines of “if you were in charge of the requirements mangement effort, what would you do?” The best answers come from folks who can say “I start here, and depending on the project, I may include a, b, c, z, y, w or if it is this kind of other project I will add in j, k & l and I round it all out with this process which includes…” Essentially, they are giving me their requirements management process “set list.” This kind of answer tells me that the candidate has enough depth of experience to know what works well, understands that process is important and that requirements management is about using the tools and techniques that are appropriate for the project.

Let’s be real though, sometimes memory can fail us.  We may not remember what works best in certain situations, or worse, we may think we remember that something works well, when it doesn’t! Kind of like when Gramps forgets that he already played a song and replays it during the set. (Cut him some slack, remember, he is 103!) What we do keep with us is the process.  Gramps does remember which notes to play and what order to play those notes to make the melody. Our analysis experience gives us the techniques to use and the order to perform them.

I know what you are thinking, “So, are you saying that Requirements Management is like playing music?” Well, I guess I do feel that way some days. The more I practice, the better I am at a particular technique. The more often I perform a particular task, the more likely I am to remember how to do that task. The more projects I complete, the wider my repetoire becomes. When I work in harmony (pun intended) with other analysts on our set list, the work produced is far better than my solo attempts. So, yes, Requirements Management is like playing music!

Thanks, Gramps, I always knew that those hours spent listening to you play would pay off!

SOUND OFF:  What’s in your Requirements Management and Analysis “set list?”

The Girl Scout Law

I will do my best to be

honest and fair,
friendly and helpful,
considerate and caring,
courageous and strong,
and  responsible for what I say and do,

and to

respect myself and others,
respect authority,
use resources wisely,
make the world a better place,
and  be a sister to every Girl Scout.

So what does this have to do with Requirements Management anyway?  There are times in my projects when I have invested hours in negotiating, documenting and declaring meeting ground rules.  This can be particularly an issue for those large, multi-day, “let’s-all-get-in-a-room-and-come-up-with-solutions” discussions.  I’m thinking for my next one, the Girl Scout Law covers it.

Let’s be real though, most of the time, we already follow these rules in our daily life.  Who doesn’t want to make the world a better place?  I think it is the combination of the qualities, the “and” part , that make me realize these would be good rules to follow in the context of a meeting.

I know what you are thinking,  “But I do follow these rules, honest, really, I’m honest!”  When I evaluate when I’m honest, I’m not sure that I am always honest and fair.  When the discussion becomes tense, I may have strong opinions, and lack the courage to voice them.  Many times I have to find the patience to be considerate and caring when steering the team out of the weeds and back to the topic.  For now, I know my weak areas lie in the “ands,” and so in my next meeting (and every day, if I am really trying to make the world a better place), I will be working on being more responsible for what I say and do.

SOUND OFF:  Are there rules from your past that would help bring clarity to your meetings?  Be friendly and helpful—tell us about them!

Responsible for developing requirements management strategy, process and plan, eliciting and documenting system requirements, driving issues and change management, participating in software testing support, end-user training, and deployment.

My short form of this is:

Responsible for translating from Human to Geek and then Geek back to Human.

Ultimately, at the core of what we do is to help our projects solve problems. What makes our role different than say an architect or developer is that we don’t usually do that in a “ta-da-here-is-your-solution” way. We listen. We observe. We facilitate. We restate. We organize. We ask questions—the obvious ones that everyone else is afraid to ask. We draw the conversation out of the team so we can all problem solve collectively and creatively.

So what does this have to do with requirements management anyway?  As we all know, the work that goes into what becomes a recorded software requirement is more than simply listening and typing. The reason I use the word “artifact” when I talk about requirements is because what we produce is the result of a process. (No, it isn’t an “artifact”  because it is an object that will be later unearthed and speculated about as to its true value.) The process is what counts. If the process isn’t good, the artifact certainly won’t be. One of the things I appreciate most about Fusion’s flexible Quality Management System is that we give our projects the opportunity to innovate and apply ingenuity, not just in the delivered solution but also in the planning process. Planning your requirements management effort involves understanding the problems you are trying to solve, and allowing the planning team to use creativity and collaboration will give the project the boost it needs to get to solutions.

Let’s be real though—we all have worked with project team members who want to do things “the-way-they-always-do-it”. My advice—pull them into the requirements management planning process.  Seek to understand what is it about “the-way-they-always-do-it” that helps them get their jobs done.  Really, isn’t this just another problem to solve, another opportunity to collaborate and innovate on a solution?

I know what you’re thinking: “But you still haven’t answered your daughter’s question!”  I was getting to that. If you are a regular Nick Jr. viewer, these song lyrics should sound familiar: “There’s no problem we can’t solve, when we put our heads together and get involved.” See, if I just put it in the same context as Kiki, Marina, Twist and Shout, she’ll get it:  “Just like The Fresh Beat Band, Mommy works with people to help them solve problems.”

SOUND OFF:  Do you have an innovation in requirements management that you want to share?  We’d love to hear how creativity and collaboration in requirements management has had an impact on your projects.

So what does this have to do with requirements management, exactly? I will say that because of the rigor, structure and deep dive required in regulated environments I have new appreciation for requirements management topics related to performance, security and privacy—topics I used to run away from.

For example, the old me:

• Performance? Isn’t that more of an infrastructure and software testing issue?
• Security? Um, yeah, what were you planning to do anyway?
• Privacy? Huh? Walk away from your desk if you don’t want us to hear your phone calls – oh you mean, privacy of data in the system! Oh, yeah, we should think about that.

Performance, Privacy and security are now some of my new favorite topics on all of my projects. The new me:

• Performance: Who is managing the performance testing effort and when do they start on the performance testing strategy? Let’s get a meeting on the calendar to discuss the thresholds we need them to test and stress.
• Security: Where are we on identifying security threats created by this system? Do we expect system features to be restricted to certain users? Have we identified authentication and authorization requirements?
• Privacy: Hey architects, what are your plans for protecting personally identifiable information? In transit and at rest? Is there a standard in this organization? Are you held to a regulatory standard?

Let’s be real though, these topics make people nervous. Privacy and security seem to be facing new regulations on a daily basis – try discussing using “the cloud” and personally identifiable information in a global solution – throw in electronic health records and payment solutions and now you have yourself a party! My favorite of these topics has to be performance. While these also make people nervous, maturity in performance testing services has made this conversation more collaborative than ever.

I know what you are thinking. “But these non-functional things are always thought about at the end of the project, when I have already moved onto to another project!” That’s usually because we don’t ask about them early enough. My experience tells me that the earlier you ask the question whether it is performance, security or privacy, the earlier you can plan for it. By encouraging discussion of these areas early in the project, we can have a true impact on their success.

SOUND OFF: Do you have experience working with performance, security and privacy requirements in a regulated environment? We’d love to hear how you address them in your process.

Since my professional life is governed by deadlines, I’m always on the prowl for analysis tools to help me produce more results in less time in order to achieve the economies of scale my work demands. Therefore, any application that supports my analysis efforts has to satisfy what I like to call, Ford’s 1^st Law of Useful Software:

An application must deliver more results than the expenditure of effort it takes to install, set up and use it.

To mitigate the time spent generating project materials, I maintain an Analysis Reference Library that contains most of the information I need to quickly bootstrap content for a variety of documents and needs. But as my library continues to expand, efficiently managing it has turned into a big headache not to mention being a real time sink!

I quickly saw the need for an application that allows easy maintenance of my library content. But prior to starting my search for the right application, I drew up a set of criteria that such a product should possess:

• To support local customer environments, the application must function across multiple platforms (i.e. Windows, Mac, and Linux) and across multiple devices such as Apple’s iPhone and iPad, Android-based smart phones and tablets, Blackberry devices, and Windows 7-based smart phones and tablets;
• Installation and setup should only take a few minutes. After installation, operation should be transparent and require no further interactions unless I initiate them;
• For ease of maintenance, the User Interface should offer standard, Windows Explorer-like functionality such as the drag-and-drop of files and folders. Ideally, the application should leverage a native platform’s own file and folder management functionality rather than implementing its own;
• The application should support file versioning and backup for easy content recovery;
• Content must be strongly encrypted during transmission to and from the application as well as during storage of all managed content;
• The application should allow file sharing among team members who may or may not use it;
• Ideally, the application should offer a free base package of functionality.

All of my product research pointed to using a cloud service. I discovered there were 5 major vendors who offered packages that might suit my needs: Amazon Cloud Drive, Windows Live SkyDrive (along with Windows Live Mesh), Dropbox, Apple’s iCloud, and finally Google Docs. I found a wealth of information on the internet describing and comparing each of these services.

After comparing each cloud service against my proposed criteria, I selected Dropbox because it provides completely transparent operation with an ease of use that consistently exceeds my “more results than expenditure of effort” rule. And storing my content in the cloud as opposed to removable media, such as flash drives, has the advantage of automatic backups and easy synchronization between any devices I’m using.

So if you share the same need to eliminate rote activities like managing files across multiple platforms, then let one of the cloud services above give you a critical, time-saving head start on quickly generating your project content!

SOUND OFF: How does your business manage document sharing among team members? Does it hold up to Ford’s 1st Law of Useful Software?

Okay, so here’s the thing. Last week, I had a conversation with a colleague about a YouTube video posted by a couple of high school girls.  Apparently the girls in the video are saying some rather not-so-nice things about another group of people.  And, as it happens with such things, the video has gone viral. So what happens to these girls?  Are they shunned for life?  Will college admissions, future employers, or future mothers-in-law google them and discover their past attitudes?  Will their Facebook posts and Tweets come back to haunt them years from now?  If only they understood that life truly isn’t whatnot—and that, no, it isn’t anyone else’s business—so don’t share it with everyone…

And just what does that have to do with requirements management, exactly?  This discussion had me thinking about requirements analysis of privacy concerns and not just “this is what we are required to do to comply with the regulatory compliance obligations of this industry, country, etc.” I started thinking about whether or not we, as requirements management professionals, should raise the issue of “and what can the user do with this system that may share things with the world that they don’t really want shared?”  When a user does this, I call it “APRES” for “After Post REgret Syndrome.”  Anyone who uses social media is likely to have suffered a case of APRES:

• Oops, I guess I shouldn’t have tweeted in anger.
• Oops, that probably shouldn’t be something that my students who are my Facebook friends can see.

To what extent should the systems’ creators attempt to warn the user of “you are about to send this to 800 million users; are you sure you want to do that?”

Let’s be real though. Isn’t the point of social media to make your life everyone’s business?  And, really, shouldn’t the parents of these girls have had a conversation about what they share?  Do we really want to be in the business of “parenting” users in our systems?  My response to these questions is, simply, our job as requirements elicitation and management professionals is to know the questions, not the answers.  And it seems we have a very real new category of questions we need to propose.

I know what you are thinking. “But my system is a closed system. It isn’t designed to be social media, so why should I bother with this new category of questions?”  I know, I know, it sounds like something we shouldn’t even raise, right?  My experience tells me that if we don’t raise the question now, we will have to address it later.  Raising it now allows the team to be ready with the appropriate requirements documentation for when your stakeholders say, “and in the next release we will allow users to share their widgets with friends they have within the system.”  And with that, you may find that the new category of questions was worth the effort.

Here’s to an APRES free 2012!

The answer I want to give is:
“When we retire the software.”

The answer I usually give is:
“Let’s talk about when we can expect to identify changes, and from there we can plan an appropriate strategy to mitigate the impact of those changes on the project.”

So what do you mean, “can expect to identify changes,” exactly?  As hard as we analysts try to predict the future, there are milestones or events that occur on software-development projects that actually drive changes to the software requirements.  For example, the minute the software quality assurance testing team has reviewed the software requirements, there will be changes.  The minute the team completes a human factors study, there will be changes.  The minute the project completes a cycle of user acceptance testing, there will be changes.  The idea is that if you predict when changes are coming, you can account for them in your project planning.  Part of that planning includes the setup of change management, which includes, at minimum, the membership, roles, responsibilities, and reporting for the change control board.  Planning for the changes allows the software development team to be organized when responding to the changes, improving the quality of the software implementation.

Let’s be real though. We can also be blind-sided by changes.  Investing in the effort to set up change management will help the project team know what is expected when those changes suddenly present themselves.

I know what you are thinking. “Look, lady, my project management methodology handles all of the change management for the team. What does this have to do with me as an analyst?”  My experience tells me that analysts should be the first in line with change management.  We have a broad perspective of the system (or at least we know whom to talk to get that broad perspective). And we have access to decision makers, both on the technical and business sides, to help understand the impact of the change.

Plan for Change; Work the Plan

Identifying the project events that drive change as you are planning the project gives you the opportunity to anticipate those changes and make room in your plans for those changes.  In other words, once we start anticipating changes, we are better prepared to accept those changes.

So what does a flexible quality system mean, exactly?  From the analyst’s point of view, a flexible quality system gives us choices within a set of boundaries.  For example, while my SOP declares that I must manage requirements (boundary #1), it also prescribes that I first write a requirements management plan (RMP) (boundary #2).  Because I customize the RMP to meet the needs of my project, I have the flexibility to decide:

• The kind of requirements artifacts and requirements model we need (for example, use cases versus structured specifications, or both)
• The process we implement that results in those artifacts (for example, big requirements meetings for stakeholder analysis, one-on-one meetings, reverse engineer existing systems)
• The workflows we set up to facilitate the long-term management of those artifacts

This flexibility of being able to make project-specific choices about the requirements-management effort empowers analysts and connects them directly the success of the project.

Let’s be real though. This flexibility and empowerment can lead to chaos if the RMP isn’t controlled just like any other project document (boundary #3).  Keep in mind that while the RMP is developed by the analysis team (and usually by a strong analysis lead or requirements lead), its purpose is to provide clarity to the requirements management process for the entire project team.  Changes to the RMP will impact all of the disciplines of the team.  It is not a good idea to surprise the software quality assurance testing team by changing the requirements model mid-project without their input.

I know what you are thinking. “Hey, lady, I have barely been given enough time to write the requirements, let alone some other document that is just going to be stuck in some project binder and locked away never to be seen again!”  Okay, okay, I get it—and here are some things you might be able to do help empower your requirements management efforts:

1. Sketch out your requirements model and include how the requirements trace to each other (even if it just for you).

2. Sketch out the tasks you need to do (or need others to do) to elicit and document your requirements.

3. Sketch out the workflow to keep your requirements up to date through change management.

4. Take a deep breath. You are empowered and you have an RMP!

So what does ‘working together’ mean, exactly?  I think this is best explained with a story about one of my recent Fusion Alliance technology consulting projects.  After being assigned to the project, my first step was to contact the system architect, who had been on the project for about a month, for the solution. As he and I chatted, he explained that the project needed an analyst because, really, they’d been running it like a “couple of college kids in a garage.”  These folks needed help!  Day one of my engagement involved sitting in the regular weekly project meeting, which gave me an opportunity to meet my business stakeholders.  Within the first week (or so) we developed a regular meeting schedule, acquired the time on everyone’s calendars, and laid out this plan (with milestones!):

• Declare a system vision in terms of features that everyone understands
• Develop system use cases and supporting requirements to detail the functional expectations of the features
• Develop user interface specifications that realize the functional expectations presented in the use cases

The use cases and user interface specifications were further divided so that the work could be completed a feature at a time, and allowed the business stakeholders to prioritize the research and background they needed to be prepared for the discussion.  Now we had a project plan that we could manage and that stakeholders could understand.

Let’s be real though. We did our fair share of juggling: last-minute meeting cancellations, pushing some features back in the schedule to pull others forward, and one of the features declared within the system vision turned out to be bigger than we all expected.  Because we laid out a coordinated plan, we easily adapted when these things popped up.

I know what you are thinking. “Sounds like a great idea, sister, but I work on a huge team. I don’t have any influence over my own schedule, let alone anyone else’s!”  I couldn’t agree with you more—been there myself. Fortunately, this isn’t an all-or-nothing deal.  Regardless of the size of our technology services projects, as analysts, we are the collaboration point, the coordinators.  Take control of what you can, and you would be surprised how effective that can be.

There are a couple of things that you can do (right now!) to align your project (you can do these things without much authority):

1. Book a recurring meeting.  It is always easier to cancel the meeting than to book it.   This isn’t a status meeting. Oh no, that’s for email.  This is a working meeting that creates peer pressure for teams to execute on deliverables.
2. Publish a simple communication plan even if you are the only reader.  Elements include contact information and responsibilities.  It is amazing what you can get done when you know whom to call.
3. Understand your decision makers.  Everyone eats lunch.  Get on his/her calendar with a lunch meeting to discuss their expectations and (more importantly) to get to know them as people.