From start to end: March 2006

A problem solving paradigm

Understand the problem
You need to be able to understand the situation and identify the root cause(s) and not just handle the symptoms.

Ask the why questions without making them sound like they are why questions. You're trying to understand the problem not lay blame. Be careful to avoid using language that is not objective or could be interpreted as finger-pointing. Telling someone, "Your transaction processing system screwed up," will only lead to a very defensive response and an escalation in tension. Instead say something like, "I think there may be an issue with the processing of a transaction. Let's investigate one through the whole process to see where the problem occurs."

Even if someone blames you for the issue, maintain your objectivity and abstain from escalating the situation.

Figure out what options you have
Identify the steps you will need to move from your current position to your desired one. Come up with different options that are available. Listen to people who have different ideas; support innovation. Be innovative and introduce different ways of reaching a solution.

Choose the best alternative
Weigh the options against each other using a SWOT analysis. Lock in on the best option and go for it.

Learn from experience
After the problem has been solved and victory declared, spend time to learn from the experience.

If new processes or procedures worked during an emergency. Perhaps they should be implemented during other circumstances.
Take precautions to ensure the same problem will not happen again.

Types of innovation

As businesses evolve, innovation becomes increasingly important for companies to survive. The new paradigm is, "The fast eat the slow." When examining the magnitude of an innovation you can use the following chart to categorize the innovation.

Improve the core business - Take something that works and add a new wrinkle to it (e.g., add a clock.)
Develop new capabilities - Find a new way to do something within an existing marketplace.
Exploit strategic advantage - Extend a competitive advantage into a new market (e.g., Nintendo extended their video game systems into the portable video game system market with the Gameboy. Nintendo can no longer claim the top position in the console market however they have the vast majority of the portable market.)
Create revolutionary change - Create a new capability for your company and use it to fundamentally change how your company operates and behaves (e.g., The introduction of the Apple Ipod and Itunes. Think of how these two products have changed Apple's business model.)

Some articles of interest for those who like innovation are:

Testing & validation

Today's post will focus on testing and validation procedures that are performed throughout a system development life cycle (SDLC.) As the different artifacts and deliverables are created, traceability and requirements management practices are used to ensure that the vision and direction for the project is maintained. Thus,

Business requirements are expanded into functional requirements.
Functional requirements lead to design documents.
Design documents lead to code generation.

Refer to the diagram below, the names used are not important but the objects they represent are.

From the perspective of testing and validation, testing is done as follows:

Code is reviewed.
Components defined in the design documents are unit tested (e.g., individually tested.)
Integrated tests are performed on components that work together (aligning with the functional requirements and architecture.)
UAT testing is performed to ensure that the objectives of the project are realized.
After the project goes live, performance against the key goals (e.g., improve throughput by 15%) are measured. Ultimately, this will be one of the factors that determines the ultimate success.

Testing & validation in detail

As new code is created, code reviews can be performed by other programmers and team members. Personally, I do not code (and am not familiar with this) so I'm going to gloss over this part.

Functional requirements are expressed as design documentation that support the requirements. Each component is tested independently (e.g., unit tested.) Inputs are simulated and the outputs examined to determine whether the component accomplishes its purpose.

Functional requirements align with their corresponding business requirements to identify the key characteristics and needs for a project. You must be able to drill back to the higher-level business requirements and down to the design documents to get the full benefits of traceability. When testing to see that functional requirements have been met, you must determine that the different functional components work with each other. Integrated testing is the key concept. Outputs from one component become inputs into the other related components. The terminology integrated system testing has been used to express this idea.

The business requirements define the objectives and measurement criteria for the project as a whole (see my post called, The sweet smell of success.) User acceptance testing (UAT) is done to ensure that the basic business objectives are satisfied (e.g., setup a marketing campaign.) Measurement against performance goals are done at this stage as well as after the project's deliverable goes live. You cannot determine if the performance goals have been attained until the end-users have been trained and passed through the ramp-up period.

Some more presentation tips

I would like to follow-up an earlier post, The soft-side of presentations, with some additional tips.

Get right to your topic using direct language. Don't use wishy-washy language. Avoid starting with something like, "I'm here to talk to you about...", "I would like to talk to you about...", "Today we're going to talk about..."
If people are having side conversations during your presentation do not say anything to stop them. Instead, slowly walk towards them. When they notice your gradual approach they will stop. This is better than asking them if they have something to add to the conversation (which they probably won't.)
If you notice that there are people attending that you did not expect, consider asking them before you start your presentation about their expectations. See if you can bridge and incorporate their expectations in with your material. If you can't do this then state what topics you will be covering and suggest a follow-up to address their needs.

Use physical presentation aids (e.g., things people can hold and feel) where appropriate. This technique makes your presentation more memorable.
When you are unsure of a question, use active listening techniques to rephrase it and confirm it with the questioner before providing an answer.
If you are speaking to a large audience, you may want to repeat any questions so that everyone can hear them.
Meet up with some of the audience members afterwards to elicit feedback and see where any miscommunications occurred. Learn from this.

Using the suggestions found on this and my other presentations posts, you'll be able to improve your presentation creation and delivery skills immensely.

Be prepared. Now go out there and break a leg! Don't be caught like this guy!

If you have any additional tips please send them to me. Thanks!

So it's still not clear?!

Suppose you are driving down an unfamiliar street and you gaze out the window to see the following sign: Speed hump. What on earth do you do?

The inspiration for this post was a short presentation I gave on effective communication. It fits in well with some of my previous posts on ambiguity (Requirements & ambiguity and Bad Practices - Part I - Ambiguity.) To understand and counteract ambiguity it is necessary to examine its causes.

Differences in perception & context
People have different experiences, backgrounds and societal influences that affect how they interpret things. Sometimes when you are communicating a message the context of the message is lost. I remember watching a DVD called, An Evening With Kevin Smith. Kevin Smith is a movie producer and writer credited with movies such as Clerks, Chasing Amy & Dogma. Before that, he was a comic book writer who penned some issues of Daredevil.

Kevin was talking to a reporter friend about the Tim Burton remake of Planet of the Apes. At the end of the movie, the astronaut gets out of his spacecraft and is horrified to see a statue of a giant ape behind him. Kevin then showed his friend a copy of a comic he wrote a few years before the movie. In the comic, an astronaut turns around and sees a statue of a giant ape and is horrified. The reporter is shocked and asks Kevin if he has any comments. Kevin replied along the lines of, "Tim Burton plagiarized me! Ha ha ha! I'm thinking of suing him! Teeheehee!" Both of them laughed it up.

Later in the week, the journalist's article came out. It came across with a very serious tone. Kevin Smith accuses Tim Burton of plagiary... Contemplating legal action. Kevin ran to the phone and called his reporter friend, "What happened to Teeheehee!?"

That was a long story but you can see how the context of the joke was completely lost when transcribed to print. When you write things down (such as requirements) you cannot communicate the context effectively so you must be very careful or it may be misinterpreted.

Use of jargon
Suppose someone tells you he just got a red herring. What does that mean? According to Dictionary.com a red herring could be any of the following:

A smoked herring having a reddish color.
Something that draws attention away from the central issue.
A preliminary registration statement that must be filed with the SEC describing a new issue of stock (IPO) and the prospects of the issuing company.

If you were working in the investment industry you might realize it is a statement about an IPO, but if you didn't, you might think something else. Furthermore, you may feel you completely understand when you don't. This is one of those times to use active-listening techniques to clear up miscommunications.

Extremely excessive overuse of verbosity
Be brief. Say a lot with few words.

Summary

Now that you know the sources of ambiguity, do your best to avoid them.

The soft-side of presentations

About two months ago I posted an article titled, "Some tips on presentations." On that blog entry I focused on prep activities, slide design considerations and other tips to use before you present. With this post, I would like to write about some tips on the actual delivery of a presentation.

Grab your audience's attention. Particularly at the start of your presentation. Tell them why it is important to them (the subject) and what you want to achieve (the objective.)
Determine to make your presentation come across as more of a dialog than a lecture. Try to generate interaction with your audience.
Give your introduction and summary slides with a blank screen. Focus the audience on you.
Exude confidence in what you say. Know your material inside-out.
If you are not comfortable or do not have genuine feelings for what you are saying, you shouldn't be giving the presentation.
Make eye contact with members of your audience. Focus in on their body language for clues to how they are receiving your presentation. This also personalizes it.
Make sure you display positive body language. No folded arms, hands out of pockets, do not nervously hold your hands and don't sway from side to side.
Relax and be natural with any gestures you use. People can tell when they're forced.
When using gestures, keep them shoulder height and above. If you are listing out points, show it on your hands (e.g., one, two, & three.)
Speak more loudly and project your voice. Don't yell! But if you are like me, you'll need to ensure you are clearly heard by everyone in the room.
Talk more slowly than when you are having a conversation. Pause... People need time to digest what you are saying. As a speaker this may feel uncomfortable, but it comes across better. What says more than words? "No words!" (Follow that link if you are in the mood for a short comedy skit.)
When answering questions unrelated to your current slide, use the B key (in PowerPoint.) If you don't know what that does, try it out (hint - it will blank the display.)
Be prepared to change the pace of your presentation every 15 minutes or so. This keeps people awake.
Do not compete with your slides, if there is a lot of text, give the audience time to look at it before you start talking.

These are some simple tips you can use the next time you have to give a presentation. Some of them will come naturally to you while others you will need to work on. In the meantime, I suggest you view presentations given by Steve Jobs, Bill Clinton and Lawrence Lessig.

In closing this post, I'll leave you with a quote that dove-tails with my request that you deliver a dynamic, interactive presentation.

Tell me and I'll forget; show me and I may remember; involve me and I'll understand.

Choose a methodology that suits your project

In some of my previous posts (The project and the business analyst & System development lifecycles & requirements) I wrote about different development methodologies that have been used for projects. These methodologies range from very process-oriented ones (e.g., Waterfall) to people-oriented ones (e.g., Agile.) One thought I would like to leave you with is that you should determine which methodology works best for your initiative.

On his blog, Harry Nieboer posted a write-up called On predicting the success of a project from the characteristics of its team members. The just of the post was that a team could make most projects work with any methodology and fail on any project with any methodology. He quotes Alistair Cockburn who concluded that, "...people's characteristics are a first-order success driver of projects!" I agree with this statement, for the most part. There are circumstances where I would favor an Agile approach versus a Waterfall model. And, there are times when I would favor the Waterfall (or other more process heavy) approaches.

Would you use an Agile approach to build an oil rig?

Let's suppose you are working on a software development project. You find that there are many different features that your client wants and that your client's needs are evolving rapidly. First off, you'll probably want to institute a change management process so you can bundle up work packages for your developers; but in terms of approaches, an Agile approach with small (e.g., 2-4 week) iterative cycles will allow you to show your client progress and give them a good look-and-feel. This approach encourages lots of feedback that will allow you to incorporate good ideas into the next iteration. After a few iterations you will be closer to meeting your client's needs. Note that, over time it may be necessary to revisit a component to modify it to work with another component that was developed later.

Alright, so what are the characteristics of an Agile approach:

Short iterative cycles.
Frequent client feedback.
Changes or evolution between iterations.
Modification of previous components so they will work with newer ones.

Under what conditions would you not want to use an Agile approach:

Suppose you are manufacturing a product (or in construction) and the different parts are made in different geographic locations but assembled at one place. I was watching the Discovery channel and they were showing a program documenting the construction of the Hibernia Oil Platform. They mentioned that some of the major compartments of the platform were constructed on 3 different continents and then shipped via boat. If the parts did not work together there would have been long delays, devastating cost overruns and (probably) lots of screaming & yelling.
You will not run into clients who will be constantly twiddling with different features and functions. There are relatively stable and predictable requirements that must be met.
The risk is too great if you don't know it upfront. Suppose you were an astronaut, would you want them to use a people-oriented process (e.g., Agile methodology) to build your moon rocket? Perhaps, but I'm sure you would express some concerns about your safety. Now if you were the NASA administrator signing the checks, would like this?

In concluding, I believe that some care should be taken when choosing an appropriate methodology for an initiative. Consider the costs associated with rework and the anticipated amount of evolution to requirements from clients as factors into your decision.

Make sure it makes sense

Believe nothing, no matter where you read it, or who said it, no matter if I have said it, unless it agrees with your own reason and your own common sense. (Prince Gautama Siddharta)

I've always been an advocate of applying common sense to one's life. It is usually the simple and eloquent solutions that work best. One thing I believe you should consider is the best way to invest your time. As with any investment, you want to get the best bang for your buck. Does the benefit associated with an activity outweigh its costs? What is the risk you are willing to bear?

For a large-scale complex project, complete traceability may be warranted. For a small budget, low risk project; is the same level of traceability required? I would suggest not.

Having a well defined methodology with structured processes and procedures is excellent. But you must be willing to be flexible when the situation warrants it. What works well under one set of circumstances will not necessarily work well in another. Use your common sense to guide you to make the optimal choice.

Requirements versus requirements management

How does requirement gathering and elicitation differ from requirements management?

Requirement elicitation refers to the process of understanding what a client wants and conveying this information to the project team so the client's needs can be addressed. Characteristics of atomic requirements are as follows: correctness, completeness, clarity, testability, and design independence.

Requirements management refers to the active management of the needs of a project. This includes things such as:

Organizing individual requirements into a mosaic that represent an initiative.
Identifying requirement gaps or situations where a high-level requirement exists but lower-level ones do not. These situations identify areas where further probing may occur (recall in a previous post Defining requirements by priority I stated that areas with minimal or low benefit might not be investigated at all. That's why I say, may.) This provides visibility into the state of the requirements and can be extended into the design aspects of a project or beyond.
Understanding how a change (or change request) to a requirement will impact other requirements; upstream and downstream. This is a function of traceability.
Ensuring consistency for a set of requirements. No contradictions please.
Reuse of components throughout. There will only be one place to make a change.

Requirements management can be done manually in something like MS Word or MS Excel, but the cost in terms of maintenance will be very high. As such, I would suggest you make use of tools such a Rational RequisitePro or Telelogic DOORS. These tools allow you to link between individual items and traverse the linkages easily. Traceability is what allows for the benefits of requirements management. However, to make requirements management useful, you must master the skill of gathering requirements first.

Think of it this way, view the gathering of a requirement as the construction of a single instrument. View requirements management as the symphony of many instruments working together in harmony.

The sweet smell of success

How do you know a project delivered what it was supposed to? How do you measure success?

For a project, you need more than simply stating requirements and then delivering them. You need to be able to show how your deliverable is providing benefit.

Did your project provide the benefits you expected?
Are you realizing more benefit than expected?
Are you not realizing the gains you envisioned?

Targets or performance metrics are setup to be used for the purpose of determining the success or failure of a project. Some projects are intended to save money by automating inefficient processes while others are intended to improve productivity. Business processes have key metrics that show their relative health and performance. Depending on the nature of your situation, some sample metrics may include:

Calls handled per hour
Transactions per minute
Average transaction time
Sales per transaction
Concurrent users

When establishing measurement criteria there are a few pieces of information that you need to consider:

Your company's current performance level. Viewing trends over time is better than a snapshot, however, this assumes that ongoing monitoring has been setup. Trends may indicate improving or declining conditions.
Understanding how companies with similar processes perform. This will give you an idea of the norm.
How much you believe the initiative can improve your key processes. Make sure that you are realistic with your expectations. If your company severely underperforms the industry average it may not be realistic to expect that you can overperform the industry after an initiative. It will take a lot of time to catch-up and then surpass the industry average.

In a previous post, Defining requirements by priority, I wrote on utilizing expected benefit and natural dependencies between components to determine which requirements you would gather first. In order to calculate the benefits, you would have had to understand how well your company is performing and how much you think you may improve performance (cost or whatever the key measure is.) In essence, your key performance metrics may already be buried within your calculations.

I feel that your key performance indicators should be identified early in the initiative. If you do not know the important drivers, how are you going to improve your business?

The project and the business analyst

A typical project's life cycle has the following stages: Discovery, Planning, Design, Build, Implement & Warranty. As a Business Analyst, depending on the stage of the development life cycle a project is in, you will have to support different types of activities.

Let's make some basic assumptions for the sake of this discussion:

The Business Analyst works on the project from inception to completion.
Ignore the different testing stages to keep everything simple.

Activities by phase

The chart below shows different activities that a Business Analyst may perform as part of a project. In general, there is more involvement in the first few stages of a project.

Let's investigate what each of these activities (in green) means.

Understand big picture: Understand the overall objectives and how the initiative correlates with business goals and strategies.
Work on the business case: Assist the project's sponsors to justify the need for the project. This may include high-level estimates of benefits.
Determine performance metrics: Projects are intended to accomplish something. This step is intended to provide you with something that you can use to perform a before-and-after examination. For example, did performance improve by the stated amount?
Gather high-level components: Understand the big moving pieces that compose the different pieces of the project. These pieces and sub-pieces will be given priorities in the next activity.
Prioritize components: Now that you understand the major components, estimate how much benefit is associated to each. Also, factor in natural dependencies between components to end up with a prioritization scheme that depicts the order in which items will be examined.
Gather low-level requirements: For the major components with the highest priority, delve deeper to identify the low-level requirements (e.g., functional requirements, specifications, process flows etc...)
Train end-users: Prior to deployment, train the end-users on the new solution.
Troubleshoot issues: After the project has gone live, be available to troubleshoot and provide support.
Hand-off to support: Prep the production support teams so they can eventually take over support for the new application.
Measure against metrics: After a sufficient amount of time has transpired, with the solution in production (e.g., end-users have ramped up appropriately), measure against the performance targets or metrics from activity 3.

Observations

In the beginning stages, a Business Analyst is trying to grasp the basic concepts of the project. Understand the what's and the why's and then delve down into the high priority items.
During the middle stages, a Business Analyst provides guidance and clarity to the design and development teams, ensuring that the team understands what the client needs and wants. Note that this does not imply providing design solutions to the design team!
In the final stages, the Business Analysts is performing a knowledge transfer to end-users and support staff. This is a precursor to the Business Analyst ending the engagement with the project.

Implications from Agile methodologies

The table below takes steps 4, 5 and 6 (Gather high-level components, Prioritize components & Gather low-level requirements) respectively and provides an example of what occurs in the real world. Before we get into the nitty-gritty, let's make the following assumptions to simply this discussion:

Each component can be broken down into groups of functionality called Requirement Sets.
Requirement sets are prioritized using their benefit as well as any natural dependencies they have.

Observations

A requirement set can be in a different stage than another requirement set. It all depends on its priority.
A Business Analyst will need to do different things based on the requirements set being worked on as it may be in a different phase than another set.

Summary

When using an Agile methodology, understand that groups of requirements will need different supporting activities because they will be in different stages of the system development life cycle.

Moving forward

Over the weekend I decided to change the look and feel of my blog. I'm using one of the default templates from Blogger with some additional scripting for items such as:

Del.icio.us tags
Newsblitz
Feedburner

Aesthetically, I think it is a little easier on the eyes though I'm annoyed that my name keeps wrapping but I can let that slide.

For my next set of posts, I will be focusing on the tasks that a Business Analyst will be expected to perform during the different activities that occur in a system development life cycle. I am using the word activities rather than phases, because the latter leads people to think of a more waterfall-type of approach.

While there is nothing wrong with that, I want you to realize that when Agile methodologies are employed, some requirements sets will be in the process of being implemented, while others will be in the process of being built, while others will still be in requirements gathering stages. Based on the stage a requirements set is in, different support activities will be needed.

System development lifecycles & requirements

One topic that I have not seen examined, is how using a different System Development Life Cycle (SDLC) methodology affects a Business Analyst's requirement gathering approach. There are many different methodologies that are used on projects. Some of the different SDLC models include:

If you view SDLC methodologies as a continuum, at one end of the spectrum you will find the waterfall model and at the other you will find the Agile approaches (the picture is based on some of the work done by a close friend.) As a Business Analyst it is very important to understand how your approach may change depending on the SDLC used. Of course, you must first speak with the project manager to clearly define and set expectations (as discussed in my previous posts: Set expectations & Time estimation.)

For a waterfall model you will want to get all of your requirements before you move to the next stage of the development life cycle (let's exclude change requests from this discussion.) Whereas when you are working on a project using an Agile methodology, you are providing discrete requirement sets based on their priority.

As a Business Analyst you must be flexible in your approach to conform to the SDLC that your project will use. When an Agile model is being employed, you must be willing and able to filter out everything that does not focus on the specific requirement set that has been chosen. For individuals that are used to a waterfall approach, letting go can be a difficult mental hurdle to cross.