Articles Archives - Page 374 of 417 - Business Analyst Articles, Webinars, Templates, Jobs

Beyond Requirements Analysis – Enterprise Analysis

Written by Alan S Koch on September 15, 2009. Posted in Articles. 1 Comment on Beyond Requirements Analysis – Enterprise Analysis

“What do your Business Analysts do?”

“They develop and manage project requirements, of course. What else would they do?”

What else indeed!

The BA Body of Knowledge (BABOK®) defines what a professional BA should know and do. Much of it is focused on requirements work – but not all. One of the knowledge areas that takes the BA beyond requirements work is “Enterprise Analysis.”

Enterprise Analysis (EA) encompasses those activities that the job title “Business Analyst” actually points toward: analyzing business processes. The majority of these activities is outside of projects, and in fact, put the BA into the position of recommending and justifying projects.

Enterprise Analysis

Analyzing business processes is indeed a big part of what we do during Requirements Analysis. But that is not the only context where this analysis should be done, and in fact, it is not the most valuable time to do it. In the Enterprise Analysis knowledge area, the BABOK identifies several other contexts in which such analysis should be done.

Activity: Creating and Maintaining the Business Architecture

As the name of this activity implies, “Creating and Maintaining the Business Architecture” is an on-going activity that has as its focus the entire enterprise. The “Business Architecture” is a model of all the business processes that are used throughout the enterprise. It shows how they work and relate to each other.

The net result of this is an understanding that most organizations lack, of how all their moving parts mesh with each other. This broad understanding of the enterprise’s processes becomes the foundation for all of the other responsibilities of the BA. But its bigger value comes in providing every member of the organization with a clear understanding of how his or her department and individual job fits into the bigger picture

Recommending and Justifying Projects

The bulk of the activities described in the Enterprise Analysis knowledge area center around proposing and justifying projects. These are activities that occur in some form or other in any organization. But with the BA’s involvement, they can provide much more value and ensure the organization’s resources are spent on the most valuable projects.

Activity: Conducting Feasibility Studies

Projects are created to solve a problem or to take advantage of an opportunity. It is rare for there to be only one available solution to a problem or opportunity, so part of project initiation involves exploring the alternatives. The BA can provide a valuable service by calling upon his or her understanding of the Business Architecture to analyze the feasibility of a variety of options.

Activity: Determining Project Scope

Scope definition should not be the first step in requirements development; it should be done during the project proposal process. How can the decision-maker(s) approve or disapprove a project without a clear understanding of its boundaries?

Activity: Preparing the Business Case

The business case is the logical argument for embarking on a project. It consists of contrasting the status quo (current situation) with the various options for addressing the problem or opportunity at hand and recommending the most appropriate option. In most cases, these options are being contrasted in terms of money (e.g., “If we spend $x on this project, it will result in $y increased revenue per year”).

Activity: Conducting the Initial Risk Assessment

An important piece of information that the decision-makers need is an understanding of the risks involved in a project. Clearly, you cannot do a complete risk-planning workshop before the project has been initiated (that is part of the Project Planning process). But an initial survey of the project risks can provide the decision-makers with key information.

Activity: Preparing the Decision Package

The BA has no authority to approve or disapprove any project. The people who do have that authority rarely have the time that is necessary to do the requisite research. So, the BA’s role in the decision-making process is to do all of the necessary research, and compile it into a form the decision-makers can use.

Activity: Selecting and Prioritizing Projects

After a project has been approved, it should not be a foregone conclusion that it will begin immediately. Projects must be prioritized against each other so the organization’s resources can be deployed in the most appropriate way. Again, the BA is not the decision-maker, but provides the necessary analysis to the decision-makers.

Project Work beyond Requirements

The last three activities that the BABOK includes under the “Enterprise Analysis” knowledge area are project-related activities that go beyond Requirements Analysis. They continue the theme of Enterprise Analysis by maintaining a broad organizational view of the project.

Activity: Launching New Projects

Here, the BA works with the appropriate people in the organization to ensure that the necessary resources, including the right project manager, are committed to the project. The BA’s unique role in these activities is to focus on the bigger picture of why the project was approved and how it fits into the bigger organizational context. This ensures that the intent of the decision-makers is honored as the project is framed and kicked off.

Activity: Managing Projects for Value

In this activity, the BA works closely with the project manager to ensure the project is tracking toward providing the value that was promised in the business case (above). The BA helps the project manager keep the project’s value proposition on track. And if the assumptions on which the project was approved turn out to be false, the BA can help the decision-makers determine their best response.

Activity: Tracking Project Benefits

In this last activity, the BA closes the loop on the business case (above). The business case proposed making certain investments in order to accrue certain benefits. After the project is over, the actual investments are known, and the actual benefits can be measured. At some appropriate time after deployment, the BA should report back to the decision-makers about how the results of the project compare with the business case. This discussion process will help the organization make better decisions in the future.

Expanding Your Value as a BA

Requirements Analysis is an important way for the BA to provide value to his or her organization. By adding Enterprise Analysis, the BA can dramatically increase his or her value by ensuring that every project fits well into the bigger picture and provides the best possible result to the organization.

Don’t forget to leave your comments below

Alan S. Koch, PMP is a speaker and writer on effective Project Management Methods. He is a certified Project Management Professional and President of ASK Process, Inc, a training and consulting company that helps companies to improve the return on their software investment by focusing on the quality of both their software products and the processes they use to develop them.

Mr. Koch’s 29 years in software development include:14 years designing, developing and maintaining software; five plus years in Quality Assurance (including establishing and managing a QA department); eight years in Software Process Improvement and 10 years in management

Mr. Koch was with the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) for 13 years where he became familiar with the Capability Maturity Model (CMM), earned the authorization to teach the Personal Software Process (PSP) and worked with Watts Humphrey in pilot testing the Team Software Process (TSP).

For more information about Mr. Koch: http://www.ASKProcess.com/experience.html.

This article was originally published in Global Knowledge’s Business Brief newsletter. (www.globalknowledge.com)

Bad Ass BA; Peer Review. Part 1.

Written by Cecilie Hoffman on September 15, 2009. Posted in Articles. 1 Comment on Bad Ass BA; Peer Review. Part 1.

Co-authored by Rebecca Burgess

Rubber Stamp or an Objective Quality Check?

When I ask for a “peer review” of a requirements document, I’m expecting a quality assurance check before the requirements document is presented to the Stakeholders. Some people think, “Oh, you’re my friend. I could never criticize your work.” But if you just rubber stamp (approve without a critical review) my work, you aren’t really my friend at all. If my friend/peer/co-worker/fellow BA doesn’t “take out a red pen” (or turn on track changes) and come back with lots of comments and questions, I worry. You would tell your friend that she had spinach on her teeth before letting her go back to the office after lunch, wouldn’t you? By the same reasoning, wouldn’t you do a careful review of her requirements document before it goes to the customer for review and approval?

There are a number of levels at which a document should be reviewed. In general, they are:

Business Case Synchronicity Check
Requirements Document Sanity Check
Requirements Statements Content Check
Requirements Document Housekeeping Check

These checks are filters; that is, if the document doesn’t pass the Business Case Synchronicity Check, you will stop the review. Only if the document and the business case are in sync, will you check for sanity, then if both of those checks pass, review the content quality of the requirements statements. Finally, do a housekeeping check on the version of the document that is ready to go to the Customer.

By checking the requirements document at each of these levels, you will be doing your peer a favor, and help her/him produce the highest quality document possible. We will detail the purpose and method for each check in articles over the next three months.

Why Peer Review?

Why bother with peer reviews in the first place? Here are a few concise reasons to use this powerful tool:

Improve the quality of the document being reviewed – More eyes are better.

Identify and correct project problems, errors, and omissions as early in the project cycle as possible – Early fixes are cheaper, by orders of magnitude.

Learn from colleagues’ insights and errors – If they can’t be a good example, they can be a horrible warning.

Broaden your knowledge of other areas of the business – The more you know about the business, the easier it is to move up to that “enterprise analyst” position.

Ask the stupid questions – see Bad-Ass BA Lessons. Part 2.

What excuses do people use to avoid peer review and how can you counter those excuses? There are many excuses, but these are the most common:

It’s scary! They won’t say this out loud, but it’s true. You must separate your self esteem from the evaluation of your work by learning to accept criticism as constructive and valued, rather than destructive and to be avoided at all cost.

It takes time! Yes, but the payback is substantial, both in minimizing the impact of errors, and in maturing the BAs on the team.

We are already behind schedule! Would you rather let the customer catch the errors? Or worse yet, miss the errors?

I don’t know anything about that project! So you’ll limit your review to the more general, BA-level comments; that’s still valuable. Also see “Broaden your knowledge” in the reasons to do peer reviews, above.

It’s hard to do! True. And these articles will make it easier, so read on….

Business Case Synchronicity Check

The requirements document needs to sync up with the business case. Really, it does. We need to check benefits, ROI claims, reporting on ROI, success criteria, and the means to validate success.

Incidentally, for this article, the business case is assumed to contain a statement of the problem that needs to be solved, who the problem impacts, and the benefits, goals, and success criteria expected to be achieved, both financial and non-financial. For more information about business cases, see Building the Business Case and/or the Enterprise Analysis section of the BA BOK.

Check the box next to the item if you can answer ‘yes’ for the document you are reviewing.

Part 1. Business Case Synchronicity

Is the business case document referenced in the requirements document?
Can you access the business case document from the reference (or could the business case be a figment of someone’s imagination)?

Is a stakeholder list available?
Do the individuals listed in the approvals section of the requirements document cover all the stakeholders?

Are the project benefits also benefits to the business? If the business sees no benefit, why is the project being undertaken?

Are the goals and/or success criteria from the business case represented by requirements (and can the requirements be traced back to the business case information)?
For each benefit/goal/success criteria, has a method for measuring the achievement of that benefit been described in the associated requirement, and does that measurement method make sense?
Are there clear requirements to provide any new data needed to measure the success of this project?
If the metric for the benefit/goal/success criteria is already implemented, has that benefit been baselined (measured in the recent past) and is the baseline data referenced in the appropriate requirement(s)?
Is there a target value and/or range for the benefit metric?

Is there a description of how and when the users expect to demonstrate achievement of the financial benefits resulting from the solution (after delivery of the project)?
Are the ROI claims (expected return on investment over a period of time) supported by requirements that describe how the business will periodically report on their progress towards achieving the ROI?

Based on the business case, do you believe that all of the critical business needs are represented by the body of requirements?

If one or more of these items is not checked, there is some risk that the requirements document does not match the business case. Your peer review mission is to convey these errors and omissions in a constructive manner. If you are expected to return written feedback, take time to explain what is wrong or missing, and provide examples if possible. If you will be participating in a peer review meeting, make notes of what you want to say so that you don’t sound too negative.

Have you convinced yourself that the requirements document and business case are in sync? No? Then the review of the requirements document should stop right now. The business case needs to be updated and everybody needs to agree that the business case is still valid. Once the documents are in sync, you can proceed to the sanity check, which will be covered in Part 2.

This article is part 1 of a 4-part series. The four sections are:

Business Case Synchronicity
Requirements Document Sanity (October, 2009)
Requirements Statements Content Check (November, 2009)
Requirements Document Housekeeping Check (December, 2009)

Don’t forget to leave your comments below

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes in software, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

User Stories – Large Misconceptions. Part 1.

Written by Robert Galen on September 15, 2009. Posted in Articles.

One of the larger misconceptions associated with user stories is that they are static; defined once and then never touched again. Another misconception is that they stand-alone as a requirement artifact. Another is that only a customer surrogate or product owner can write them. And finally, many miss the power of the acceptance tests as a clarifying vehicle for the story.

Over my next two posts, I want to address each of these in turn. Not only should these approaches help your user story writing, but your general requirements definition clarity and understanding should improve as well. And these misconceptions also assist distributed, non-local teams in eliciting stories that are more meaningful where they struggle to maintain active face-to-face communication.

User Stories are Organic!

If you study Scrum and product backlogs at all, you’ll realize that the backlog list of user stories evolves quite dynamically over time. Usually stories are created in a Story Writing Workshop at the beginning of a project effort. In this case the stories are often ill-defined and quite large-epics or even larger.

Coming out of the workshop, there is a tremendous amount of work to do on refining the stories, but certainly not all at once. The metaphor to keep in the back of your mind is – Tip of the Iceberg! You only need to refine the stories that are 1-2-3 or so iterations (Sprints) away from actual execution.

As you move forward, delivering those pre-defined stories, you actively groom the stories moving up on the backlog-getting them prepared for execution. Typically teams groom their product backlogs weekly. The process serves to refine the clarity surrounding each story. Often it will lead to other stories-breaking them into more meaningful units and discussing dependencies. Themes or packages of stories will emerge as well, as the product owner and team think about how best to couple stories into meaningful chunks for delivery.

The last and probably most important part of the dynamic is that the team factors in ongoing progress (execution velocity) and learning into their grooming.

While working with remote or distributed agile teams, it’s important to participate in these grooming sessions as a team. In this way, everyone is involved in the real-time conversations that are naturally part of backlog evolution.

User Stories are not a Catch-All Artifact!

The key driver for the content of requirements within agile team is the team itself. Let’s say a team member encounters a user story in a backlog grooming session that is simply too ill-defined to understand or estimate. However, they do understand the story well enough to suggest that-if they had a use case with it, one that was designed like one they’ve used/encountered before, they would have sufficient clarity to proceed.

In this case, they’re suggesting supplementing the Story with a known additional artifact form.

This is great!

Instead of trying to embellish the story as-is, simply link it to the newly created use case. In fact, it’s perfectly acceptable to link stories to all sorts of well known or used artifacts in your organization – traditional requirement (SRS) specifications, forms or templates, traditional use cases, agile use cases, wireframes, etc. All can effectively come into play to enhance and supplement your understanding of individual stories.

The caveat is that you don’t want to do this for every story. Let the individual cases or needs emerge from the team! Don’t create them too far in advance and certainly don’t create all user stories with the same level of detail. These extensions must come as requests from the team, i.e., they’re pulled as needed-preferably right before the implementation in the next iteration (sprint). Thus maintaining the just-enough and just-in-time nature of your story evolution.

One of the benefits of this approach is within distributed teams. These situations typically need richer documentation density with their requirements and this approach certainly provides it, while still maintaining an agile requirements approach.

As a final note, Alistair Cockburn has spent some time establishing the notion of Agile Use Cases. More information can be gleaned here on that topic – http://alistair.cockburn.us/Agile+Use+Cases

Next post, well finish with the other two misconceptions

Don’t forget to leave your comments below

Robert Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].

Improv Comedian Turns Business Analyst

Written by Kupe Kupersmith on September 15, 2009. Posted in Articles.

If you want to separate yourself from other BA professionals in the market, please read on.

Here is a quick background to the story. In the early 1990s I was working as an accountant and bored to tears. My father was proud because I was using my college degree to earn a living. As you all know using your college degree is not necessarily the reason you should stay in a career. To help with the boredom I started going to see a lot of stand-up comedy. One night I caught one of Jimmie “JJ” Walker’s shows. You remember him, right? He coined the phrase “Dy-no-mite” on the show Good Times. I could not believe it…he was terrible! That night I turned to my girlfriend, now wife, and said “I can do this.” I started working the open mic night circuit in Atlanta then auditioned for an Improv troupe. When I was selected for the troupe after the audition, I never went back to stand-up.

Throughout the 1990s I rarely missed a weekend being on stage and practicing two to three nights during the week. Over that time, I transitioned from an accountant and subject matter expert for PeopleSoft Financials into a business analyst role working on PeopleSoft implementations.

I no longer perform with a troupe, but I use much of what I learned as an improv comedian every day to help me succeed in my role as a business analyst.

Why should you care? The skills I am about to share with you focus on the most important skills to elevate your career as a business analyst. It has nothing to do with 99% of the skills most people discuss like use cases, workflow diagrams, etc. All of those are important, but most BAs can learn when and how to use those techniques. In my opinion, learning those techniques is the foundation for being a great BA. You need to separate yourself. The skills learned from my improv days will help you break free from the rest.

First, let me give you a little background on Improvisational Comedy from wikipedia.

“Improvisational theatre (also known as improv or impro) is a form of theatre in which the improvisational actors/ improvisers use improvisational acting techniques to perform spontaneously. Improvisers typically use audience suggestions to guide the performance as they create dialogue, setting, and plot extemporaneously. The basic skills of listening, clarity, confidence, and performing instinctively and spontaneously are considered important skills for actors to develop.”

Here are five lessons from my improv days that if you work on will help you be a better analyst and separate you from the pack.

1) Over-Prepare then Go with the Flow

To be spontaneous on stage, my troupe would practice relentlessly so that we could relax on stage and let the scenes take shape as we performed. Since there are no scripts in improv we would practice being comfortable not having scripts. The more we practiced, the more prepared we were for any situation on stage. In business analysis the more prepared you are for a meeting with stakeholders the smoother it will go. Make sure you know what you are trying to accomplish with every meeting and have a list of questions you want to cover in an interview. Then when you have that meeting, go with the flow. Don’t go down your list of questions one by one. Have a conversation with your stakeholder. Let your stakeholder speak about the topic you want to learn more about and ask clarifying questions to make sure you touch on all the points you wanted to cover. You’ll get your questions answered and then some.

2) Never Deny

Never say no. In improv if someone walks into a scene and exclaims “Wow, I love that you colored your hair yellow,” you never say “it’s not yellow.” That denial instantly puts the burden back on the other actor to come up with something else. It kills the scene. If you did it enough the other actors wouldn’t want to “play” with you anymore. In business analysis, our business stakeholders come to us with changes in scope. This will always happen, so accept it. If you always say “No, sorry that was not in scope”, your stakeholders won’t want to “play” with you anymore. After clarifying the need I’ll say something like “we can definitely add that feature, let me work with the team to see what the impact on the cost and schedule will be. Then we can discuss if you still want to include it in this release.” Doesn’t that sound so much better? You keep the dialogue moving forward. You come across as a team player. By not denying you help make an informed decision on how to move forward.

3) Always Give 100%

I can still remember a scene where I had to come in as a boy from England. One thing I was never good at was accents. But, I had to go for it. I could not leave the other actors out there. I squeaked out a few words in an English accent and then fell into my standby Latino accent. I came across so believable because I did it with confidence. I worked into the scene somehow that I was a long lost cousin that came to live with family and never lost my accent. The crowd loved it. As business analysts we need to be confident when presenting to an audience, facilitating a requirements workshop, in a one on one interview, and all other interactions we have with our team and business stakeholders. Confident, not cocky! In what ever you do give it 100%. You can always look back later and see how you can improve. I still can’t get an English accent right to this day!

4) Don’t Anticipate

In improv you can not anticipate your lines. You need to listen intently on what the other actors are saying and then develop your lines as you go. The minute you stop listening to come up with a line, you are done. Most likely your line will not make sense. When you are eliciting requirements you need to actively listen to your stakeholders and not anticipate their answers. Many of us have industry knowledge and assume we know the answers to some of the questions. Remember you are not the subject matter expert. There is a reason you are talking with the stakeholder. Listen to their response and then clarify their response by developing follow-up questions.

5) Include Your Audience

Improv is all about including your audience. We would get suggestions for topics to incorporate in scenes, we often went off stage and continued scenes in the audience, and we even brought some audience members on stage. By including your audience in this matter we would break the fourth wall, as they say in the biz! So many people love improv theatre because they feel part of the act. As analysts you need to break the fourth wall with your audience. Requirements elicitation, analysis and communication are team sports. Don’t sit in your office and document requirements the way you think they need to be documented. Get everyone involved in your planning and consistently include your audience in reviews, let them know your status. This will make everyone feel a part of the effort and take responsibility for its success.

Best of luck with your next improvised day.

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected]

Follow me on Twitter, http://twitter.com/Kupe

Reinventing the Resource Chart

Written by Mark Jenkins on September 8, 2009. Posted in Articles.

Click on small images to enlarge

As we continue to examine traditional tools reinvented to establish effective communication, let us look at the resource chart. I’ve seen varying approaches to resource charts such as using graphs, spreadsheets, and Gantt charts; and while each of these methods yields results, the approach detailed in this article will improve the amount of information communicated in a single resource chart rather than using multiple diagrams. In short, this article concentrates on a technique that portrays layered meaning in a single chart.

As with the swim lane diagram, discussed in two August issues of Business Analyst Times, (http://www.batimes.com/articles/106-articles/453-reinventing-the-swim-lane-diagram-part-1.html) the resource chart will be constructed using Visio, replete with stencils, which will accelerate chart design time. This technique for creating resource charts serves four main goals:

to communicate what my team is currently working on, what we have completed, and which projects are scheduled to commence;
to provide insight into time spent on each individual project;
to give guidance about the status ofan individual project;
to facilitate,through a single diagram,the percentage of available time for each team member.

If you have similar goals then you should find this technique quite useful. I should point out that my team generally works on simultaneous projects tracked over a maximum three month period. In addition, this technique isn’t a way to define an actual end date (I use MS project for that).

Using some of the basic concepts of the previously discussed swim lane diagram, each team member is assigned a lane, referred to as a “resource lane.” Added to the header, along the x axis, are annotated blocks to represent periods of time. Two week blocks are appropriate to my situation, although individual adjustments can easily be made. Using a typical paper size, landscape oriented, the two week blocks line up nicely with financial quarters (three months of the year). Here, as with the swim lane, a version and author are very important. To ensure that the same version is being used by all, I update my resource chart at least a couple of times a week.

Now I add the resource lanes for each group member. Each of the resource lanes are used to demonstrate an individual’s allocation to a particular project or effort, which is shown as a percentage along the Y axis

and measured in time along the X axis.

In the following example, I will demonstrate using four team members with their corresponding resource lanes.

All the components of the diagram used so far can be added to a Visio stencil, which allow future charts to be created quickly. In a moment, we will fill in the detail, but first let us build the legend to define it.

The legend is divided into three main columns. Within each column are three possible measures, represented by boxes in various shades and patterns, referred to as resource bars.

The first column resource bars (colored green, amber, and red) demonstrate if an effort is on track. When a project is completed, the resource bars should all be green.

The second column resource bars demonstrate proposed/future scheduling that is yet to have an accurate time line, allowing vacation, business travel, and out of office time to be booked out.

The third column resource bars identify regular tasks, the current date, and items that are in queue but not yet defined.

These resource bars, annotated using the appropriate color and style will be added to the resource lanes, at the appropriate dates (x-axis) and percentages (y-axis), to show how long an effort will be sustained.

Starting with Mark, in July he worked on three projects simultaneously (maybe after reading the Bad-Ass BA series…!). Project A took up 25% of his time, Project B 50% and Project C another 25%, for the whole of July. As a result, Mark’s resource lane, with three resource bars, would look something like this.

It is more likely though that resourcing realities will produce situations where projects are completed at different times, potentially freeing up more resource availability. For Mary, this was what happened during July. She worked on two projects, one project for two weeks at 30% and then her remaining time in July was taken up on another project. Her resource lane looked like this.

Adam has a regular task that takes up 25% of his time, such as allocation to support tasks, project roll-outs etc. This resource bar is stretched along the entirety of the resource lane, using the appropriate color as per the legend. He also took a week of vacation at the start of July, after which he worked on a project which, at the time, had some minor issues.

I’ll fast forward a little and fill out the rest of the resource lanes, to bring the diagram to the current date (Aug 25^th)

We now have a clear picture of the teams resourcing. We can see that two of the projects in the group have some issues. We can see vacation schedules, business trips and can now easily demonstrate what the group is working on, down to the individual level.

One of the major strengths of this technique is that it is great for planning. You can easily identify when resources will come available. You can actually plan, at a basic level, as far out as you like. I use a different color and designation for planned effort that I have a rough or S.W.A.G. idea of how long it should take. These speculative resource bars are added to the resource lane.

Adding further to planning possibilities, you can also begin to assign projects not yet defined, or in a future queue.

Finally, to further aid the reader, a line representing the current date is added which makes it simpler to see where current date is, in comparison to the data.

The diagram is now complete and so we have created a simple but highly readable chart to demonstrate how a team and/or individual is resourced, has been resourced and will be resourced. In adding the current date line (vertically, in red) the diagram posits a more real time view, which is perfect for a team web site and/or regular distribution fulfilling weekly or daily status reports.

As I mentioned at the start of the article, the four main goals for this diagram were achieved through this layered approach to the resource diagram. Over time, I have realized another major benefit from using this approach whereby employing this diagram prevents my team from being swamped by a deluge of new projects that are awarded high or immediate priority. In such a situation, the stock approach as a manager or executive is to immediately assign a team member to work on this new, high priority project; however, this new resource chart enables the manager to negotiate realistic work loads and time lines to sustain a balanced work flow. A manager is now deftly able to present how an effort should to be prioritized or scheduled by way of a visual aid that is universally understood.

Upon completion, the final illustration in this example looks like this.

Don’t forget to leave your comments below

Mark Jenkins is Manager Business Analysis Group at Websense. Mark has spent the last year establishing a formal Business Analysis Group at Websense that now plays an active role in all major business projects. As part of the development, he created new process and documentation standards, which assisted in the overhaul of IT Project processes, placing the BA Group at the forefront of the IT to business interactions. He can be reached at [email protected]