From start to end

Making change requests tangible - the home reno

2010-07-11T12:49:00.006-04:00

The cost of change requests are sometimes difficult for a client to visualize. This is especially true with software development projects. There is just nothing tangible a client can wrap their mind around. 200 lines of C+? 400 lines? What's the difference?

To make the impact of a change request more tangible, I suggest using an example most of us can relate to - home renovations. Last fall, I had a series of basement renovations performed. One component was to add a partial wall to split an area of a room off (notice the wall on left.)

After the installation of the initial studs and drywall, I decided the wall should be a little longer. This would provide me with the option of putting larger pieces of furniture on the other side (e.g., more shelves.) The contractor had to use more materials and time to extend the unfinished wall.

Had I realized my requirement for a longer dividing wall earlier, it may have saved my contractor some time (because I caught this early I didn't waste any materials.)

Now that the renovation is complete you can't even tell the wall was extended. I got what I wanted even though it took a little more time.

For arguments sake, suppose I figured out I needed the wall extended after all the painting, floors and baseboards had been installed. Considerably more time and material cost would have been incurred. Why?

If my contractor needed to remove flooring, drywall and repaint - I would have wasted a lot of materials. Some of the flooring and baseboards would have been thrown out, additional paint and priming time would have been required, etc... All of this costs money.

On a side note, the wife of a friend of mine was also performing a renovation - the kitchen. She decided to replace the marble tile pattern she had picked for the backsplash. She made this decision after the tiles had been bonded to the walls, grouted and treated (so oil wouldn't damage them.) My friend literally cried... he understood the impact.

The moral of the story - the earlier you can identify the need for a change the less costly it will be.

Avoiding inertia and estimating how long it will take to write requirements

2010-06-27T18:39:00.004-04:00

Back in 2007, I decided to take a couple of months off from writing on this blog. A few months stretched into a few years really easily. Once a habit is broken, it's very easy to give into inertia. I guess this is why one should aspire to never miss a workout.

Recently, I received an email from Georgia on one of my posts in which she asks, "..., I was wondering if you have any tips on how to estimate how long it will take to write requirements for a project you've been assigned to. The project is new, you know nothing about the business, how can you provide an estimate? Should you just give a high-level estimate and then adjust as you go along and see the progress?"

Why do businesses execute projects? To improve how things work, to meet regulatory and compliance requirements, to capitalize on new opportunities or avoid potential threats.

At some points in your career you'll be asked to work on projects where you have little to no expertise. Don't be discouraged however, this is how we learn. What approach should you use to estimate how long it will take you to write requirements? Here are some thoughts:

Decompose the project into the key basic business processes which will be impacted (e.g., billing, order entry, inventory reconciliation, campaign deployment, etc...)
Create a matrix using the business processes versus the different stakeholders involved - such as finance, marketing, customer service, warehousing, etc...
Indicate which teams are involved in which processes and which team is the ultimate owner of each process (who do you go to if you need a decision.) The more teams involved, the more potential stakeholder complexity.
For each process indicate how complex you feel it is. If you don't know much about the process, rely on the stakeholders and management for guidance.
Using the information you've gathered determine which processes have high, medium or low levels of complexity. As a rule of thumb you could say high = 10 days, medium = 5 days and low = 3 days.
Add up the total number of days and this will provide a really rough estimate.

Understand this is merely a high-level estimate and as further analysis is performed the estimate will become more precise. This is project estimation after all. At the start, you might provide an estimate with 100% contingency, however as the project starts to execute the level of contingency drops as more things become known.

One side benefit of using the matrix is it will also help you plan out your requirements gathering sessions (you know exactly who needs to be involved for each process.) Use this to secure participation from those teams and your project's sponsors.

Random thoughts on being service-oriented

2007-07-31T22:27:00.000-04:00

Currently, I work in a support group in the IT department of my company. Our group assists other IT teams by scheduling, assessing impact and coordinating deployments to our production systems. In essence, these are the services we provide. For the purposes of this posting, this is my frame of reference when I say service-oriented.
Random thoughts on improving your customers' experience:

Think about things from the perspective of your customers. Perspective is everything after all.
Take your own medicine - go through the process yourself. Have you ever come across a user interface where you wondered, "What were they (the developers) thinking?!"
Don't be a cold heartless bureaucrat. It's important to your customer; make sure they know it's important to you.
Do things which provide benefit and value, not because you're following a checklist.
The process you steward can be a part of a much larger one. Never forget it. When someone asks for help but it's in another area, make sure you explain to them how the larger process works and your piece in it.
When you need to pass a client onto another service team, do it personally if possible. Make sure the transition goes smoothly.
Acknowledge the requests you've received and set expectations for completion.
Provide updates when you're running late and won't be able to meet the expectation.
Follow-up afterwards and ask for feedback.
People shouldn't use your services because they have to. Don't tell them that. People should use your services because they want to! Be ready to market the benefits in a tangible way.

Webinar: Trace requirements to business intent

2007-07-20T00:22:00.000-04:00

Compuware is providing a webinar on July 26 @ 2:00pm EDT. You can register following this link.

Practical techniques: Trace operational and other non-functional requirements to business intent
More and more there is increased pressure to develop applications that are closely tuned to business processes and yet can be changed on a moment’s notice to reflect new priorities.

Achieving balance between business goals and the associated operational requirements set has been a challenge. Too often different stakeholders are defining the business (domain experts) and operational (technical experts) perspectives. This can lead to disconnects in the systems delivered, requiring expensive rework either late in the development cycle or in post-production maintenance releases.

WIIFM - What's In It For Me

2007-07-17T22:10:00.000-04:00

I remember sitting through some of my directors' presentations listening to them talk about, What's In It For Me, or WIIFM for short (not to be confused with the Nintendo Wii - which I play but suck at.) The basic idea was while you worked hard on projects you were also learning, developing new skills and getting new experiences. WIIFM for everyone!

In a few of my blog posts I've written about how important it is to adjust your presentation and communication to your audience. In effect, you were telling them, What's In It For Them. It's all about creating a relevant experience to sell an idea, product or concept.

Now let's step back and examine this WIIFM concept applied to another situation. Have you ever worked on a project where you have an idea on how more success can be achieved if the project team were to work more collaboratively with other project teams and personnel? In my experience the typical project manager response is, "It's not my problem," or, "It's outside of my scope," or, "It's someone else's problem." Then you step back and watch the car crash in slow motion; the problem manifests itself and severely impact the project and company as a whole.

I liken this to Adam Smith's (the Father of Economics) "invisible hand."
As every individual, therefore, endeavors as much as he can both to employ his capital in the support of domestic industry, and so to direct that industry that its produce may be of the greatest value; every individual necessarily labors to render the annual value of society as great as he can. He generally, indeed, neither intends to promote the public interest, nor knows how much he is promoting it. By referring the support of domestic to that of foreign industry, he intends only his
own security; and by directing that industry in such a manner as its produce may be of the greatest value, he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention. Nor is it always the worse for the society that it was no part of it. By pursuing his own interest he frequently promotes that of society more effectually than when he really intends to promote it. I have never known much good done by those who affected to trade for the public good. It is an affectation, indeed, not very common among merchants, and very few words need be employed in dissuading them from it. (Adam Smith, The Wealth of Nations)
Basically, this means each individual acting in his (or her) own self-interest will lead to a better outcome for the society as a whole; or WIIFM but on a project-scale. The problem with this is simple. No one ever builds roads and the infrastructure to connect things because it's in no specific person's best self-interest; but that's not my problem. Is it?

I'm not saying expand a project's scope, merely understand how a project fits in with the big picture.

Someone else's shoes

2007-04-25T23:48:00.000-04:00

Continuing from my last post, spending a day in another person's shoes will give you an appreciation and understanding of their point of view.
Try this simple exercise - Drop any preconceptions or notions you may have and pretend you are in the position of one of your clients or end-users. Do a little role-playing to increase your empathy.

What would you want or need to be successful?
Why would you want it? What would you do with it? What's the value?
When would you need it?

By no means do I suggest you use this technique to gather requirements for a client, however, it will help you look at things differently and with a more open mind.

Change your perspective

2007-04-21T21:22:00.000-04:00

Perspective influences how you view the world. It allows you to see things in a different light than another person, but it can also keep you from understanding their point of view. When you are gathering requirements from a client, having empathy enhances your ability to understand their needs.

Benefits of being able to view things differently:

Allows you to be open-minded, receptive and patient.

You learn to think like your client. In some of my engagements, I found my clients could not articulate exactly what they wanted. I needed to perform a lot of facilitation to help gather and define requirements. Being able to think like them allowed me to probe more effectively and determine the underlying objectives.

Because you understand your client's point of view, you can anticipate their next question. This is an excellent value-add to your ability to provide service.

Changing perspective isn't a foreign concept. If you have ever created user stories, you have in essence used an approach that incorporates the different perspectives of the people involved. User stories are easy for the different parties to understand -- clear communication is always the goal.

Make understanding your client's perspective a part of every engagement.

Webinar: Getting the Right People on the Right Projects

2007-04-08T11:15:00.000-04:00

Getting the Right People on the Right Projects (Wednesday April 18, 2007 @ 2:00PM EST)

Completing projects isn't enough anymore. The real challenge is building applications that are on target, on deadline, and on budget, to save your company money and provide a competitive edge. Therefore, ensuring you've got the right people on the right projects at the right time is more important than ever. That means effective project management.

Slew of webinars and resources

2007-04-03T20:54:00.000-04:00

Why requirements definition is a critical first step (April 18, 2007 @ 1:00pm EST)

Managing your requirements is only half the battle. For management to be truly effective, taking the first step of defining complete, accurate requirements is absolutely critical. In this webcast, Forrester Senior Analyst Carey Schwaber will explain how you can build agreement around requirements right from the start, so there are no uncertainties down the road.

Aligning Business and IT (on demand)

Many CIOs are struggling in their quest of aligning IT with the corporate business strategies, objectives, metrics and culture. CIOs need to become more involved in the development of strategic initiatives and build an understanding of the corporate and line of business missions and goals if they seek to align IT with the corporate directions. Moreover, CIOs need to interpret that knowledge into a flexible IT strategy if the alignment is to succeed long-term.

Business Intelligence Trends (podcast)

As business intelligence (BI) evolves, new trends emerge. But whichimportant BI trends should you pay attention to? And how should yourorganization incorporate this information into BI strategies?

Webinar: Bits and bites

2007-03-16T23:51:00.000-04:00

BPM: Aligning People, Process & Technology
Monday March 26 @ 12:00pm (EST)

Join Paul Harmon, Executive Editor, BPTrends and Principal, BPTrends Associates and Roger Burlton, Founder, Process Renewal Group and Principal, BPTrends Associates, for an insightful and lively discussion about the advantages of aligning your people, processes and technology to achieve improved enterprise performance.

Deliver what the business expects
One of the webinars mentioned in a previous post has made its slides available as well as access to a 2006 IDC research white paper by Ballou.

Building trust

2007-03-06T20:41:00.000-05:00

A business analyst bridges the communication gap between different parties through precise communication and understanding. Part of this process requires the development of strong working relationships with clients, or more simply, client management skills.
Like any relationship, professional or personal, establishing trust, confidence and credibility is of the utmost importance. Here are a few of my suggestions:

Set expectations. Make sure your clients understand the necessary inputs and outputs from the engagement. Make sure they understand their own role.
It's all about execution. Do what you say you will do. Develop a plan and show your are executing against it. This improves your client's transparency into your activities as well as shows your accountabilities.
Present the good and the bad. By nature a lot of us will 'sugar-coat' the bad things or make them small footnotes. Present the bad news and its impacts however, provide options, alternatives and recommendations.
Be able to justify your work. Be prepared to run someone through your thought process. I remember one instance where I had prepared reporting showing assets under administration a few hundred million dollars short of the previous month. Naturally the lead accountant questioned my data. I walked him through the process of developing the report and after he saw the diligence and supporting numbers he agreed with my conclusion. Afterwards, he never questioned any of my work and was always satisfied with the results.

Whenever you are starting an engagement with new clients there is a feeling out process. This is your opportunity to set the stage and provide exceptional value-add service.

Webinar: Deliver what the business expects

2007-02-16T00:50:00.000-05:00

Compuware is providing a webinar entitled, Deliver what the business expects, at 2:00 PM EST on February 27, 2007. Here's a brief synopsis:

By establishing a sound requirements gathering and management process and tightly aligning it with QA and the rest of project life cycle, IT can deliver relevant and business-facing applications faster and more efficiently. IDC’s November 2006 research white paper, "Driving Effective Requirements Through Quality Coordination for Adaptive IT/Business Collaboration," by Melinda-Carol Ballou shows that leading global companies are looking deeper within the IT organization to deliver competitive advantage.

Webinar: From Process Understanding to Business Innovation

2007-02-02T00:18:00.000-05:00

ebizQ will be hosting a webinar called From Process Understanding to Business Innovation on February 6, 2007 @ 12:00 PM (EST.) Here is a brief description of the event.

Transformation and innovation are the cornerstones of your success. It's no longer enough to be efficient. Business innovation is the name of the game if you want to stay ahead of your global competition. But enhancing customer experiences, increasing operational agility, and re-thinking the way you create value is no easy task. It requires you to change and continually improve your processes.

Business intelligence basics

2007-01-28T04:07:00.000-05:00

Business intelligence is defined as,

The process of gathering information about a business or industry matter; a broad range of applications and technologies for gathering, storing, analyzing, and providing access to data to help make business decisions.

While I am not an expert in this field I do have a fundamental understanding of the key concepts. The picture below shows a high level view of a simple business intelligence configuration.There are:

Source systems which gather the information that will be analyzed.
Information from the source systems are stored in their native databases or other data sources. Typically the database are configured for speed of processing. This is good for processing transactions quickly but bad for analyzing them.
Information from the data sources goes through a process known as ETL where the data is extracted from the source system, transformed (to meet business needs) and loaded into a data warehouse. Many different data sources can be consolidated.
Information from the data warehouse is made available to end-users in the form of data marts where the data is organized to answer specific types of business questions (e.g., sales data can be cross referenced by product, region, time, sales representative, etc...)
Finally, reporting and analytic tools are used to analyze the information in the data marts. This genre of reporting tools are known collectively as on-line analytical processing (OLAP for short.) There are a few different variations of OLAP tools: MOLAP or multi-dimensional OLAP and relational OLAP or ROLAP. Each has its advantages and disadvantages. For more information on OLAP I suggest going to the OLAP report.

Considerations

Do you need real-time reporting? Is it important to understand what is going on right now? By nature, most business intelligence configurations update their information at a frequency insufficient for real-time reporting.
Are there standard reporting needs or are reporting needs of a more ad-hoc nature? The answer to this question my mean that one of MOLAP or ROLAP may be more relevant.

Webinar: Requirements-driven testing

2007-01-26T00:55:00.000-05:00

There's a webinar offered by Compuware called, Requirements-driven testing—The journey from business needs to test and user acceptance. The event will occur on February 6, 2007 @2:00 pm EST (11:00 am PST.) Here's a brief description of the event.

IDC’s research indicates that 70-80 percent of IT project failures result directly from poor requirements gathering, management and analysis. With a requirements-driven testing approach, you can improve the quality of your requirements, involve QA earlier in the life cycle and maximize the ability of your projects to deliver on all of their objectives.

Decisions and consequences

2007-01-23T23:13:00.000-05:00

Early last year I wrote a post called, Thoughts on decision-making, where I outlined some decision-making techniques and myths. One item I would like to add to that topic is to understand the consequences and ramifications of the decisions you make.
Let's step back and examine this from a business context. Suppose we are working on a project and one of the requirements is simply, "to be able to process transactions from external sources." The design team proposes two solutions:

Processing batch files
Processing individual transactions (real-time)

Based on cost estimates, the batch file solution seems more appealing. One should consider whether, in the foreseeable future, real-time processing is desirable and whether the benefits of that approach will outweigh the increase in costs. It may turn out that the batch file design still wins out but the ramifications of the decision are fully understood and can be communicated.

You may think the consequences of a decision will be minor and short-lived, but they may become temporary like income taxes.

Ode to preparation

2007-01-09T20:29:00.000-05:00

There's a short but interesting post on Mark Cuban's blog, Blogmaverick. He paraphrases former Indiana Hoosiers coach, Bobby Knight, "Everyone has got the will to win, it's only those with the will to prepare, that do win."
When you are working on business requirements, presentations or anything at all, good preparation will improve your performance. Words to live by.

Tips for end-user acceptance

2006-12-26T23:13:00.000-05:00

Any solution, no matter how well it has been conceived will not be successful unless it is embraced by its intended end-users. Here are some quick tips to help promote acceptance (though I don't guarantee it.)

Understand how end-users work: Find out why they do the things they do. If you show an interest in them, they will be more comfortable with what you're trying to accomplish.
Provide opportunities for feedback: This is particularly important when there are user interfaces involved. At regular intervals, let people see the development and direction and be willing to listen to suggestions and feedback.
Manage change: If something has to change let your customer understand the rationale. "Because it has too..." is not a useful response. If the change is meant to make things better explain how.
Make it seem familiar: People by nature are resistant to change. Perhaps there is opportunity to gradually phase in changes (smaller changes are easier to digest) or provide an interface that is similar to an existing one.
Enlist champions: End-users that can teach other end-users are a great way to provide support. It also gives the champions a sense of ownership for the adoption. Early adopters are good individuals to use as champions.
Teach don't point: When someone asks for help one of the worst things you can do is point them to a manual. Spend time to teach them how it works. Show them they're important.
Measure & report: If the new solution is meant to improve productivity, show them the gains that have been made over time as the end-users become more familiar and move up the adoption curve. This type of information shouldn't just be provided to the project sponsors and management.

Projects are usually justified quantitatively based on achieving benefit targets (e.g., gains in efficiency or increases in sales.) Maximum benefits will not be achieved if the end-users do not embrace the solution wholeheartedly.

Why we do things - ROI

2006-12-22T00:14:00.000-05:00

Long ago, one of my professor's told me, "The purpose of education is to increase pleasure enjoyment." I've yet to fully grasp exactly what he meant (he was a professor of philosophy and often spoke in riddle), but I think it was something along the lines of, "Knowledge allows us to improve our station in life." It may take the form of allowing us to obtain better jobs, improve our ability to appreciate things or allow us to take better advantage of the opportunities presented to us.

Let's examine a familiar concept - investing. Whether it is because we want to be able to make a large purchase (a house or car), enjoy a comfortable retirement, or live out some of our dreams, most of us are putting money aside. This money is invested based on our individual risk / reward preferences. If you lie awake at night worrying about your investments, you may be outside of your risk / reward sweet spot.
Individuals who want to be safe, invest in financial instruments such as money market mutual funds, treasury bills or other assets where the risk of losing the investment is small (note that small risk generally implies small potential return.) Individuals with a higher risk tolerance purchase financial assets with higher potential returns.

The prudent investor analyzes their assets periodically to ensure a suitable return on investment (ROI) is being realized. There is a good guide on ROI available on SearchCIO.com explaining basic ROI concepts from a business perspective.

I want to introduce another concept - opportunity cost. Opportunity cost is defined as:

The cost of an alternative that must be forgone in order to pursue a certain action. Put another way, the benefits you could have received by taking an alternative action.

In business, all else being equal, you fund projects that have better rates of return for your company. Businesses use capital from their shareholders and money they've borrowed to fund their projects. Furthermore, a company is expected to invest in projects with ROI that exceeds their opportunity costs (e.g., projects that make them grow!) From the perspective of an individual investor you probably wouldn't be willing to purchase shares in a company that wasn't trying to increase its future earnings. Would you?

Thus, in business the ultimate goal is to increase profitability. A business does this by undertaking projects that are expected to yield a return above their opportunity cost. These projects have specific goals and objectives that support the business' strategy. This is why it is important to tie requirements back to business goals and objectives. As well as business goals and objectives back to strategy.In business and in our personal life, we do things to improve, to grow, and as my old philosophy professor would say, "...To increase pleasure enjoyment."

Webinars: PPM & ITIL

2006-12-12T22:21:00.000-05:00

Here are some webinars that may be of interest. Note that you may need to sign-up to get access to them.

Project Portfolio Management for the Skeptical IT Organization
You want to run IT like a business; you know Project Portfolio Management (PPM) can get you there, but you are worried about long implementations, high price tags, and consultants taking residence in your shop. In this webcast you'll learn how a web-based model with the right level of functionality has helped organizations like yours get a PPM solution up and running in two weeks and producing value right away.

Part I: Introduction to ITIL for the IT Executive - Podcast - Expert Podcast
Based on a practical approach to addressing real-world challenges of IT service management, ITIL allows organizations to better package and deliver IT services to their customers. ITIL enables IT organizations to align their capabilities with business requirements.

Leadership styles

2006-12-05T21:14:00.000-05:00

I remember taking a course developed by the Leadership Research Institute on leadership styles. The purpose of the course was to help identify the most appropriate way to interact with an employee given an understanding of an individual's:

Ability to perform a task.
Motivation level to perform a task.

Using these two factors to create a simple matrix you get a picture similar to the one below. For each quadrant a different approach is warranted for handling an employee.

High ability to perform the job but low motivation to do it. Convince the employee to persevere and outline the task's importance.
High ability to perform the job and motivated. Allow the employee to perform the task unhindered. There is no need to provide direct support or exert control.
Not able to perform the job and not motivated either. Basically you need to tell the employee exactly what to do to complete the task and monitor his (or her) progress.
Not able to perform the job but motivated to try. Provide support, feedback and guidance to help the employee complete the task.

These guidelines assume that you are able to determine the competence and motivation level of an individual.

Intuitively, this framework makes sense. When you understand how to perform a job well and are highly motivated to do it, you don't really appreciate someone looking over your shoulder, telling you what to do and asking for constant status updates.

The purpose of the course was to improve managing employees, however, I feel that these fairly simple guidelines can be used in any situation where you need a task performed by someone other than yourself.

Tips for Business Intelligence

2006-11-28T21:53:00.000-05:00

There was a short set of slides posted on BaselineMag.com outlining 6 Tips for Business Intelligence Success. Make sure you check it out. The tips are:

Understand your enterprise
Involve key users
Make sure components of a BI system work together
Be mindful that different employee groups will want different interfaces
Consider making applications broadly available
Create a competency center

Some of these tips are applicable to normal business analyst engagements as well.

Knowing when it's good enough

2006-11-20T20:47:00.000-05:00

A business uses cost-benefit analysis as one of its evaluation criteria when deciding whether to pursue an opportunity or not. One concept central to this is the assessment of potential risks. To me there are a few components to risk assessment:

Likelihood of the risk materializing. What's the probability of the risk becoming a problem?
Potential cost (monetary, compliance or reputation) to mitigate the risk. How much is it going to cost you? This also includes implementing any mitigation strategies.

Combined, these factors provide a value to each risk. Risk assessment can be applied in many different areas:

Managing the risks encountered in a project.
Understanding the importance of a defect or bug in a system.
Managing financial assets.

For the purposes of this post I'm only going to write about the second item.

What do you do if you find a defect or bug in a system? You evaluate it to determine whether it's a show stopper or whether you can proceed despite it. Creating bug-free software is the ultimate goal but it has cost and time implications. Here's a quote from an article, They Write The Right Stuff, from Fast Company about a specific software system.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

The piece of software in question runs the NASA space shuttle. The consequences of failure could result in the deaths of the astronauts, the loss of a multi-billion dollar piece of hardware and many years of setbacks to the space program. Many of the systems we deal with in the business world do not have this level of criticality. In my past jobs I have worked with time sensitive trading systems where 1/2 second delays mean losses in the $10,000's of dollars. On other projects, variances in marketing and market research data were explainable ("Yes, someone did purchase 50 rolls of toilet paper and it skewed the numbers.") We need to understand when something is good enough as it is instead of always trying to be perfect.

How "bad" requirements can stifle innovation

2006-11-17T22:23:00.000-05:00

A great way to curb innovation and creativity is to impose improper limitations.

Limits by themselves are not bad. Clearly a project needs to operate within a set budget, resource allotment and delivery schedule. These types of constraints can actually spur creativity and novel solutions.

But let's think about business requirements and how improper requirements can hinder the process of innovation. More specifically let's examine how requirements that are not design independent can unfairly constrain a solution to a business opportunity (or problem.)
Many times during my requirements gathering and elicitation engagements I have heard subject matter experts and clients tell me their requirements based on existing applications and functions. They assumed that the products delivering the new capabilities they desired would actually be enhancements to the existing applications. In truth, the eventual solution may be based on an existing one (particularly with software products), but this is not always the case.

Suppose our company designs cars. The newest set of requirements for the upcoming model year state the driver has the ability to:

Determine where he / she is (e.g., location) at all times.
Receive driving directions to a user specified address.
Interact with the system through the car's dashboard.

By themselves, these requirements seem fairly benign. Suppose our project advanced to the stage where we are developing a solution to meet these needs. Our team decides that a global positioning system (GPS) is required. Based on the third requirement, it is decided that an on-board system similar to Onstar is appropriate. Implementing this solution requires our company to purchase units of the GPS product and integrate it into our assembly (line) process.

Nothing appears terribly wrong with the proposed solution, but what if the car model in question is marketed to first time car buyers and students (people who want to be sporty but on a budget.) Large scale changes to an assembly line are costly. Acquiring GPS units and integrating them into a car's electronics are expensive. The cost of the new model will increase as a result.

Because of the third requirement we have ignored other solutions that may have been more optimal. Perhaps we could have offered portable GPS systems (e.g., Tomtom's) to people who purchased our vehicles. Our needs would be met in a more cost-effective manner.
The third requirement constrained our innovation and creativity to the point where a more optimal solution was missed. This is how a requirement that is not design independent can stifle innovation and creativity.

Understanding the goal

2006-11-14T21:32:00.000-05:00

When gathering requirements, one of the most important things to understand is the answer to the question, "Why?"

The answer to this simple question will provide clarity and guidance to your requirements gathering efforts. This is because you will be able to evaluate whether the requirements you are gathering will solve your problem (or capitalize on the opportunity.) Thus, a business analyst should always seek to understand the underlying business objective.

Suppose a client receives five sets of different reports. The client is concerned because it takes him a long time to get the necessary reporting. His request is for his five reports to run faster so he can perform his analytics. The business analyst (doesn't probe any deeper and) works with the IT developers to optimize the SQL used in the reports, create database views to reduce the number of multiple-table queries and revamps the reports so they are more efficient. Finally, the business analyst presents five optimized reports. The client promptly looks at each report, takes two pieces of information from each and then creates a dashboard sales report for one of his customers.

If the business analyst knew that the goal was to prepare a dashboard sales report, could a more optimal outcome have been achieved?

Here are a few comments about what happened:

The requirements were not design-independent. It was pretty much determined to rework the existing reports and make them more efficient.
Ultimately, a useful result was obtained however, it may not have been the most optimal one. The business analyst also ran the risk of not achieving the goal at all because the business analyst did not probe deeply enough to uncover the underlying objective.

If the business analyst had used active-listening techniques and probed the client, both of these issues could have been avoided.

How does your project contribute?

2006-11-08T19:50:00.000-05:00

I recently attended a training session called Business Acumen. A good amount of the course's material was dedicated to understanding financial statements (the company providing the training was affiliated with the National Association of State Boards of Accountancy.) The rest of the course's material was based on the book, What the CEO wants you to know: Using business acumen to understand how your company really works, written by Ram Charan.
The main point of the book was that all businesses, regardless of their industry have the same underlying principles.

Cash - Money and near-money equivalents used to fund a company's operations.
Margin - The amount of money left over after paying off expenses (for a product.)
Growth - The rate at which a company's business expands.
Velocity - The rate at which a company's assets can be used to make money. For example, inventory turnover is a measure of velocity in some industries.
Customer - Consumers or potential consumers of your products and services.

The interesting part of the training session was trying to understand how your activities (or project) contributed to the well-being of your company. Basically, a project should be contributing to one of more of these elements. For example, a company setting up an e-commerce website would be trying to:

Increase the market for its products (especially if it did not have a web presence.)
Increase the growth rate for the business by increasing the potential sales opportunities.

If you or your project is not contributing to one or more of these principles, then you should reevaluate what you are doing.

Getting past the fog

2006-11-07T00:53:00.000-05:00

There was an interesting article on Yahoo! recently titled, A Guide to the Latest Batch of Corporate Buzzwords. It's a short piece and examines the usage of corporate jargon and lingo.

A new crop of buzzwords usually sprouts every three to five years, or about the same length of time many top executives have to prove themselves. Some can be useful in swiftly communicating, and spreading, new business concepts. Others are less useful, even devious.

Delayering, rightsizing, unsiloing ... What do these terms mean? Step back and think about how much terminology you use each day that an outsider would not be able to understand.

Using inappropriate language will only further confuse and obfuscate your message. Simplicity and clarity should be valued above all else.

Setting expectations

2006-10-29T21:11:00.000-05:00

In the business world, a key part of communicating is expectation setting. Whether you are delivering a presentation or a set of requirements, not establishing expectations with your audience can lead to a few unfortunate outcomes.

Your material is perceived to be unsuitable. It may be too detailed or contain too few details.
People may require you to perform additional work to produce something more acceptable to them. You'll get comments like, "I won't sign-off on this unless I see... such-and-such in there."
Your work is not perceived to be relevant. You'll be asked to go back and start over.

In marketing, there is a saying that, "If you do not position your product, someone will do it for you." Likewise, when communicating, "If you do not set expectations, they will be set for you." Think of what happens when you watch a presentation (or attend a meeting) with 10 other people. How many of them say things like,

I didn't get anything from that.
That wasn't what I expected.
There were no details, I need details.

If you hear these sorts of statements, it indicates that people did not have a clear idea about what to expect and why there were there. In other words, the individuals responsible for delivering and setting up the presentation (or meeting) did not clearly articulate their intentions.

In one of my previous posts, I wrote about expectation setting as it related to the development of requirements. What resources you'll need access to, what tools you will be using, how you will be providing status updates and the facilities to provide feedback (and ultimately sign-off.) The last part of this is to explain and outline what will be in the actual deliverable.

Before I start writing about expectations for deliverables, recall that there are many different phases to a project's life cycle and for each one, different levels of information and different audiences are present. For each, a different expectation needs to be established.

Spotlight: business analyst

2006-10-22T00:55:00.000-04:00

Allan Hoffman recently posted an article on Monster.com, Career spotlight: Business Analyst.

He lists the main factors for requiring more business analysts as:

The increase in outsourcing patterns.
A continuous drive for improved efficiency.

Mr. Hoffman points out that the most important thing a business analyst can bring to a project is translation; or a furthering of understanding about what is required.

Kathleen Barret, president of the International Institute of Business Analysis (IIBA), says business analysts' ability to translate -- an ability that's difficult to offshore -- is crucial to succeeding in the role. "[Business analysts] need to be there with the business," she says. "It's very difficult to do a good job virtually."

This echoes my thoughts from an early post, The why of business analysis. The central role of the business analyst is to foster understanding throughout the business and IT groups to provide the best basis for success.

Step back for a second, think about how easy it is to misunderstand and miscommunicate. Think about the costs and consequences associated to some of these misunderstandings when they happen on your projects.

Unfortunately, they aren't as humorous as the following video.

Requirements in an agile world

2006-10-15T20:39:00.000-04:00

In my last post, I wrote about differences between projects that use a traditional project methodology versus ones that employ a more agile one. In the post, Choose a methodology that suits your project, I spoke of when you should use one methodology over another one. Is there an impact on requirements from different methodologies?

Recall the main characteristics of good requirements:

These factors are essential to all requirements. However, when using different methodologies there are slight variances a business analyst should expect. The two pictures below show my thoughts on the key differences.All business analysts should be aware of these differences and the impact to their deliverables.

Agile Project Leadership Article

2006-10-02T23:07:00.000-04:00

There's an interesting article on ProjectConnections.com called Agile Project Leadership. In it the author, Kent McDonald compares and contrasts traditional project management characteristics versus agile project management ones.

To summarize the article, the basic differences were:

Task versus feature driven.
Process and control versus anticipate and adapt.
Fully detailed versus iterative project plan.
Leadership versus team driven.

To this set of differences I would like to add something from one of my previous posts, System Development Life Cycles & Requirements,

Process versus people-oriented.

If project management characteristics change depending on the nature of the approach taken, what about the approach to requirements? What differences would one expect to see? What concepts are important?

VIDEO: Excessive Jargon

2006-09-29T22:35:00.000-04:00

Here's a short video that parodies what happens when you use too much jargon. No one understands anything!

Disaster Recovery, Requirements Management & Alignment resources

2006-09-27T12:13:00.000-04:00

Here are some resources I've come across that may help you.

Requirements management
Best Practices for Enhancing Project Success is a recorded webinar that you can watch at your leisure.

More than 70 percent of software project failures can be traced to poor requirements management. The root cause: the gap between what the business team wants, and what is communicated to IT for delivery back to the business.

Disaster Recovery
CIOs lack confidence in their DR plans

IT execs are insecure about their disaster recovery plans.

That's according to a new survey by Rochester, N.Y.-based Harris Interactive Inc. that reported 39% of executives polled gave their plans a letter grade of C or worse, revealing a troubling lack of confidence in disaster readiness.

The survey results also indicated that this lack of confidence in disaster recovery planning is growing. A similar survey conducted in 2004 found that only 24% of executives gave their plans poor grades.

ALL-IN-ONE GUIDES: Disaster Recovery

This All-in-One Guide will get you on the path to a good, solid DR plan and show you what you need to do to maintain it. It starts you off with DR planning and design with understanding recovery capabilities and tools, and then takes you right through to DR implementation, security and testing.

Alignment
IT/Business Alignment

The IT/business alignment topics page provides CIOs and IT management with up-to-date information and resources on budgeting, IT governance, IT spending, leadership and strategy, and Return On Investment / Total Cost of Ownership.

Power Within

2006-09-23T15:13:00.000-04:00

On September 13, I had the opportunity to attend a Power Within speaking engagement being held in Toronto. The event looked very promising with speakers such as Micheal Eisner, Sir Richard Branson and Tim Sanders taking part. You can see the full details about the session here.

Micheal Eisner's speech on management was very interesting. He spoke about how Disney used inside-the-box thinking to spur creativity and innovation for their entertainment initiatives. This may sound contrary to the outside-the-box paradigm that is prevalent now, but what Mr. Eisner meant was that for a given project you must understand the size of the box (e.g., amount of resources and money you will devote to it) and innovate, manage and be creative within those confines. He used clips from movies such as Who Framed Roger Rabbit, The Lion King, Outrageous Fortune and Pirates of the Caribbean - Dead Man's Chest to illustrate his points. The complexity concerning things one would not give much thought to was astounding. The example shown was the shading on Roger Rabbit's character while a overhead light swung back and forth (the picture is courtesy of Disney via Google.) This was something that was extremely challenging to perform at that time.
Tim Sanders was a former motivational coach at Yahoo! Mr. Sanders was an engaging speaker and talked about what he termed the, "likability factor." The basic premise is that people who are more likable are more prone to succeed versus an equally competent but less likable individual. He reasoning (backed up by lots of research) was as follows:

People want to work with individuals they like.
People will be more willing to assist someone they like. Such as give them information that will provide an advantage in a negotiation or a business deal.
When choosing between two identical proposals, the one from the individual you like more will generally win.

Mr. Sanders pyramid of likability was as follows (I've stated it upside down):

Friendliness - Make people feel welcome and comfortable.
Relevance - Validate commonalities between yourself and others.
Empathy - Understand feelings are facts. Be a good listener. Don't judge or try to fix the problems.
Realness - (At the top of the pyramid) be genuine. When someone is talking to you, give them your complete attention.

The keynote of the event was Sir Richard Branson. I must admit that this part of the event was a little of a letdown. It was run as an interview session with questions from the audience. Mr. Branson has significant charisma, however I did feel he rambled and didn't necessarily answer questions the audience's questions.

The event itself was good on a whole. If you can find a session keynoted by someone like Bill Clinton, I'd definitely say to check it out!

Webinar: Harnessing Emerging Technologies

2006-09-22T17:28:00.000-04:00

Here's an interesting webinar, How to Harness Emerging Technologies to Boost the Bottom Line, from Ziff Davis.

Why do innovative companies find benefits from emerging technologies that others overlook? How do their IT teams use new technologies to create products and services and add value for customers? How do they help drive business innovation and keep competitors at bay?

View it on-demand here.

1, 2, 3 align your projects!

2006-09-19T21:11:00.000-04:00

What are the steps involved in aligning projects to a strategy?

There are many different projects that a company can undertake. The first step is to create a list and make sure that everyone understands what each project is about.
Determine the criteria you will use. Your criteria should match your strategy and be representative of the direction you want your company to follow. For example, if you want to be a low cost provider, one of your potential criteria could be, "that a project should reduce the costs of service or increase the efficiency of providing service using your call centre."
Some things are more important than others. Weight your criteria.
Let the project sponsors individually score the importance of the projects using your criteria. Tabulate the results to reduce bias that the sponsors may have towards a one project or another. Projects that score high align more closely with your company's strategy and direction.
Establish high-med-low groups of projects.
The groupings and individual rankings form a basis for prioritizing.

By the end of this process you will have determined objectively which projects align better with your overall strategy and goals. Note that there are factors other than strategic fit that determine which projects will ultimately be undertaken (e.g., compliance, ROI.)

Webinar: Getting Agile with Your Projects

2006-09-15T18:47:00.000-04:00

There's an upcoming webinar that maybe of interest.

Wednesday, September 27, 2006, 2:00 pm Eastern, 11:00 am PacificTap into the power of Agile software development with Dr. Alistair Cockburn, one of the forefathers of the Agile movement, and learn important risk-reducing strategies for your projects. Developing executable code that offers business value is the heart of project delivery, and using tools that support the collaboration and distillation of business rules and requirements into automated test suites is imperative. Fergal McGovern, originator of Optimal Trace, the leading Requirements Definition and Management Tool, will outline how a structured approach accelerates successful project delivery.

Enroll here!

Video: Cubicle wars

2006-09-14T20:09:00.000-04:00

Sometimes you need a laugh. Courtesy of Windward Reports and Youtube.

Project prioritization goals

2006-09-12T20:26:00.000-04:00

Continuing on from my post, Why prioritize projects?, prioritization is important because,

It provides focus to the more important initiatives. Companys can concentrate on what really matters to them and not be distracted by the latest fad.
Money, time and people are scarce resources. Proper management and effective use of these resources can only benefit a company.
In order to prioritize projects you much be able to compare them against each other objectively. This apples to apples comparison removes bias from decision-making.
Clear direction and visibility to everyone in the company, not just the main decision-makers. Everyone is on the same page. We all know what can happen when things are not clear.

Stop 'gathering' IT requirements

2006-09-07T21:40:00.000-04:00

There's a post on Techrepublic titled, Project Managers: Stop "gathering" IT requirements.' It's an interesting read.

And when I ask why projects get bad requirements, the answers are, "Users won't tell us what they want," or "We don't ask good questions," or "What they told us they wanted turned out not to be what they really wanted." But I think that the problem is more subtle than any of those answers.

The author, Paul Glen's, point is that, "project managers should negotiate requirements among the stakeholders." My comments on the article are as follows:

In order to negotiate well, a project manager really has to understand the nature of the project and client ask. If the project manager doesn't understand the ask (e.g., isn't familiar with the business), a strong supporting cast is needed to keep everything real. Are you more confident when you know your project manager has lead projects similar to the one you are on or is very familiar with the industry?
Requirement 'gathering' means collecting requirements, however, a business analyst is paid to understand them, derive meaning from them and then communicate the underlying business objectives. To me, this is the core competency of the role. The article does not really talk about this. You do not need a business analyst to order take.
The following comment from the article seems a bit over the top, "We should think of a set of requirements as being like a multilateral treaty among a group of nations." I understand the need to have clear understanding and expectations, but this sounds like something people do when they don't trust each other.

I think, if anything, this accentuates the need to have a strong capable business analyst.

Why prioritize projects?

2006-09-06T19:36:00.000-04:00

Projects are initiated to capitalize on opportunities (the Chinese character for crisis is the same as opportunity I've been told) that a company faces. However, not all projects are created equal.

To quote George Orwell's Animal Farm, "All animals are created equal, but some are more equal than others." Some projects are more beneficial than others.

Prioritizing projects is very much like managing investments. In fact, it is the same. How likely are you to perform due diligence before making an investment decision such as buying a bond?

You need to understand:

The anticipated returns
The potential risk
The timing of the returns

With this information you can perform a net-present value calculation to determine the value of one investment versus another. Combined with other factors such as your risk-tolerance and investment goals you'll choose the most appropriate ones for you. The purpose of all of this is to introduce objectivity into your decision-making.

Extending this principle to project prioritization means you should:

Understand how important a project is to you. How well does it align with your objectives?
Prioritize your projects early to allow for lead time for effective decision-making.
Introduce objectivity into your prioritization process. Just because someone yells loudly does not mean his project is the most important.

Do not take the position that:

Prioritized projects must be executed sequentially. Some minor projects are dependencies for others. Some projects are easy to slot into non-peak times.
You only prioritize when you need to make a decision. The earlier you prioritize, the more potential problems you can avoid before they become critical.

It's a bigger world

2006-09-03T21:57:00.000-04:00

We've all encountered situations where difficult decisions had to be made concerning a project.

Should we continue?
What features do we need to pare back?
Do we need more money?
Are we missing needed skill sets?

These decisions are normal things that occur within any project. However, the ramifications for handling them may impact things outside of the project in question. What if an increased budget means another initiative has to go unfunded? Or perhaps the added resources need to be taken from another project's resource pool?

Instead of managing a specific project, decisions have implications across a collection of inter-dependent projects. The management of the collection is termed program management. The purpose of program management is to use the scarce resources and funds available to orchestrate projects to deliver maximum benefit. If you've taken basic economic theory you may remember the definition of scarcity.

The basic economic problem which arises from people having unlimited wants while there are and always will be limited resources. Because of scarcity, various economic decisions must be made to allocate resources efficiently.(Investopedia.com)

It's true, you just can't do everything!

One thing I was told very early about projects is that, "Projects end. If it doesn't, then it's not a project." If that's true, then programs, being a collection of projects, end as well.

But we also know that businesses constantly evolve. Their products and services are impacted by innovation and change caused by internal or external sources. If you will, the portfolio of service offerings evolves continuously. To me, I view this evolution as portfolio management. Clearly, this terminology evolved from finance however, it is also applicable to the management of a company's set of offerings and how they are transformed over the passage of time.

The art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk vs. performance.

Expanding further upon the concept of program-wide decision-making is the notion that decisions across a portfolio can have implications in many of the different programs within it. A portfolio is governed by the higher level strategic goals of a company whereas program decisions are governed by lower level objectives.

For example, suppose one of your strategies is to become a low-cost provider for a given product. Your product development team may look at projects that reduce the cost of the materials used while your service team may reduce the number of agents who handle customer inquiries and beef up the self-help sections of your website. Together, these two programs work towards meeting your strategy.

Rebranding

2006-09-01T18:05:00.000-04:00

Doing some housekeeping on my blog.

New layout and colours.
Blog posting labels.
Blog archive is now expandable for easy searching.

Figuring out the hard way what works and doesn't work with Blogger's new Beta.

Performancing.com scripts.
Adding and reordering page elements does not always work.

10 ways to give a bad presentation

2006-08-29T10:21:00.000-04:00

Here's a short article called, "10 ways to give a bad presentation," from Techrepublic.com. It reinforces some of the points alluded to in my previous posts. Enjoy!

Strategy and direction

2006-08-26T23:25:00.000-04:00

Business strategy is one of the most important things for a company. Some companies have a vision statement, a mission statement, followed by strategies to achieve the mission and implemental tactics to meet the strategy.

The basic premise is that people understand what they are working towards and why. Focus and clarity are the keys.

Guy Kawasaki suggests the use of simple mantras to provide direction rather than 60+ word MBA written, jargon-filled mission statements.

A mission statement that doesn't provide focus or clear direction does what exactly?

Here are some mission or vision statements from some companies. Tell me if you know what they're doing. Do they provide direction?

3M is a diversified technology company with a worldwide presence in the following markets: consumer and office; display and graphics; electro and communications; health care; industrial and transportation; and safety, security and protection services. What makes us so diverse is our ability to apply our technologies often in combination to an endless array of customer needs.

At IBM, we strive to lead in the invention, development and manufacture of the industry's most advanced information technologies, including computer systems, software, storage systems and microelectronics.

Alliance Data partners with its clients to develop unique insight into consumer behavior. We use that insight to create and manage customized solutions that change consumer behavior and enable our clients to build stronger, mutually-beneficial relationships with their customers.

Great companies will call Alliance Data first to create more loyal and profitable customer relationships.

Always earning the right to be our clients' first choice.

Ultimately, simply having a defined mission, vision or mantra is not enough. You need direction and a clear objective so you can tell if you are getting closer or further from your goal.

Building a presentation - Part 6

2006-08-22T22:22:00.000-04:00

The presentation has been given and now it's time to assess what happened.

Get feedback from audience members informally where they can be open and honest. Allow yourself to be receptive and clear up any issues. Make note of what is said, it will help you the next time.
Do they want more? A great sign!
Try to determine what can work on in terms of your delivery. Personally, I know I have a difficult time slowing down my speaking as well as speaking loudly.
Follow-up with people after the fact to see if your message has sunk in.

Learn from your experience and knock them dead the next time!

Building a presentation - Part 5

2006-08-20T15:44:00.000-04:00

I gave a quick run through of my presentation for the individual setting up the session. This opportunity was used to confirm that I was on the right track and to gather additional information to make the presentation more personal and appealing.

Things that I learned that would helpful included:

Additional issues facing the audience. Now that I know all of their issues I can make sure that my presentation dialog addresses them.
All of their reservations about the chosen requirements management product, Telelogic DOORS. Many people have developed first impressions of the product based on what they've heard from other individuals. One of my goals is to educate them so they can develop more informed opinions (on the product.)
Obtaining specific examples of problems this team has had with requirements and requirements management in general. Nothing hits home as well as this.

All my demos are ready. My handout props are set. Now if I can just remember my own presentation tips I'll be good to go! My revised presentation is available on esnips.

Webinar: Using ITIL to Align IT with Business Requirements

2006-08-15T20:19:00.000-04:00

Here's a link to an on-demand webinar that may be of interest. Below is the description.

Increasingly, enterprise IT organizations are managing IT as a set of defined, customer-facing services. This concept of IT service management allows IT organizations to better package what they do for their customers and to more closely align their capabilities with business requirements. The worldwide de facto standard IT service management framework is the UK-government developed IT Infrastructure Library (ITIL). ITIL provides guidance on the most fundamental IT operations processes and is used by leading companies around the world for risk reduction, quality improvement, legislative compliance, and cost control. This webcast will introduce IT service management and ITIL with emphasis on the fundamental concepts and principles that IT executives need to know during the decision making process.

Building a presentation - Part 4

2006-08-13T21:59:00.000-04:00

My basic presentation has been assembled as per the plan found in my last post. I'm still preparing my demo scripts and getting ready to do a short mock presentation for one of the individuals helping setup this meeting. Any feedback or suggestions I get from the mock-up will be incorporated into the presentation. Additionally, I still need to take into account presentation best practices to help the delivery.

You can find a copy of my version 1 presentation on my enips.com account. The name of the presentation is: RM & Tools v1.0 - small.ppt. If you have any comments or suggestions feel free to tell me about them.

Building a presentation - Part 3

2006-08-08T19:33:00.000-04:00

Let's continue on my building a presentation series with the next stage which is to map out and plan my presentation using the information gathered previously in the 1st and 2nd articles. To recap, the objective of my presentation is to introduce requirements management techniques and Telelogic DOORS to a team that is skeptical of the software tool.

Assemble the material
I've looked through my existing material and saw a decent PowerPoint presentation titled Clarity in my esnips.com account. There were also, earlier incarnations of requirements management presentations I had laying around. I'm sure I can reuse some of this material.

I am definitely going to have to come up with some demonstration scripts and new slides to show benefits etc...

Major components to present
Here is a summary of the major components I want to include in my presentation:

A demo of loading an MS Word requirements document into Telelogic DOORS. All of their requirements exist in this format. This will show how requirements can be migrated into the software package.
A demo showing traceability and its application to a project. Traceability is what will allow this team to assess the impact of a change.
A demo illustrating how to export requirements from Telelogic DOORS to a more readable MS Word format. Before I go through this demonstration, I will show them requirements from a project that does this without telling them. This demo will bookend the presentation with the first demo.
Tips on how to get the most out of requirements management. To ensure clarity, modularity and make requirements testable.

Map the material to an appropriate presentation style
In a previous post, "Use the right presentation style to convey your message," I wrote about some templates for presentations. One of them, "selling an idea," seems to fit in with my objective. Based on that format, I will lay out my presentation as follows:

A simple statement of purpose. To show how good requirement management practices and requirements management software can benefit the execution of projects.
An articulation of the audience's needs. Currently there is little / no documentation. The team has a difficult time assessing the impact of a change in requirements.
An illustration of the features of good requirements management practices. What are traceability, modularity, verifiability and clarity?
The benefits that can be realized by the team. What benefits do these features yield? Let's load in a requirements document to the product.
What's wrong with the status quo? We need to change because we have difficulty understanding the impact of a change in requirements. What does this change affect? Who knows!?
Reconfirmation of the benefits. Now let's manipulate some of the requirements within the product and show how we can understand the impact.
What we need to do to benefit. What steps do we need to take to improve?
Complete the 'sale.'

Next steps

Assemble the material as per my plan.
Follow presentation best practices.
Give a quick rendition of my presentation to one of the individuals helping set up the meeting. This will ensure that my presentation speaks to them.

Do you see what I see?

2006-08-01T20:55:00.000-04:00

I've been goofing around with a Nintendo DS Lite trying to reduce my Brain Age (I'm hovering around 23-24 for anyone interested.) One of the more interesting exercises in the game is something called the Stroop Test.

The Stroop Task is a psychological test of our mental vitality and flexibility. The task takes advantage of our ability to read words more quickly and automatically than we can name colors. (University of Michigan)

The object of the test is to say the color not the word. For example, if you saw BLUE, your answer would be, "Red!" The Brain Age test is basically to answer 50 of these items as fast as you can.

This got me thinking about how this relates to business requirements and clarity. One party sees, "Red," while the other sees, "Blue," even though they are both looking at the same thing. Furthermore, both parties think they understand completely. Hence, techniques like active-listening need to be used.

Of course, the Stroop Test probably won't work if you have a condition called synesthesia, but that's another story. A common form of synesthesia results in an affected individual seeing letters and numbers in color.

Building a presentation - Part 2

2006-07-26T22:49:00.000-04:00

Continuing from my last post,...

I decided to do a little more research into my audience, their backgrounds and perceptions.

What I uncovered
A few members of the audience have worked previously as business analysts. They are familiar with basic requirements gathering. None of them used requirements management tools and all attested to using MS Word.

As we have some Telelogic DOORS users at my company, some of the audience members had already seen the product and developed impressions about it such as,

I can't export my work (to MS Word.)

Why it's important
This information provided insight into how I can alter the content and structure of my presentation to be more effective to this group of individuals.

I was originally thinking of doing 2 demos. One to show the loading / creation of requirements and the other to show how to link requirements together. However, it seems apparent that a 3rd demo on how to export a requirements document from Telelogic DOORS to MS Word-friendly formats is required. This demonstration would overcome the, "I can't export my work (to MS Word)," angst.
The audience does have experience as business analysts; though I would say that collectively they do not have a lot of experience. Also, since they use MS Word, they are probably more used to writing full paragraphs and sentences versus atomic and easier to test requirements. Thus, I may want to include some examples on how to make requirement statements more clear.
Because these individuals have done some requirements work in the past, I probably do not need to express why it is important to have good requirements.
If they've only used MS Word documents, they have probably never really had decent requirement traceability and modularity. I'll want to show them the benefits of having these qualities.
My audience will be composed mainly of people who I would say are logical thinkers. They like hearing facts and being shown proof!

Moving forward
Armed with this knowledge, I have a better idea of what type of material I need to cover and what things I don't. I also have some ideas on suitable approaches for them (e.g., logical arguments and demonstrations.) On to the next step of assembling material and defining my structure!

Building a presentation - Part 1

2006-07-23T20:46:00.000-04:00

I've been asked to give a presentation on requirements management (more specifically Telelogic DOORS.) The purpose is to show how these things could be used within my company to help a particular business team. What I'd like to do in my next set of posts is walk you through my thought process developing this presentation. Let's start!

Know the audience
Looking back to an old post on presentation tips, one of the first things I need to do is understand my audience.

Who are they? A group that provides front-line support to data analysts who use a variety of data analytics and reporting products.
What is their background? Their backgrounds vary (I'm going to need to look into this more) but the team members (on average) have been with the company for less than a year.
What problems or opportunities are they facing? Little or no documentation on existing reports and processes. Hard to assess the impact of changes across the body of reports they maintain. They gather requirements for new data products and are expected to help bring them to fruition with the IT team. Currently, requirements are captured in MS Word and MS Excel (report mock-ups.)

Plan the presentation

Do I need a formal presentation at all? Verbal only? Will it be projected or given in a more 1-to-1 fashion? I'm going to be presenting to a group of 6-8 people so a visual presentation is probably more appropriate. I won't really be able to tailor it specifically to one individual.
What is the objective? The purpose of the presentation is to introduce Telelogic DOORS and requirements management. The message I'm trying to get across is basically to , "sell them," requirements management techniques and tools. This fits in well with the presentation template, "selling an idea," from my post Use the right presentation style to convey your message.
Do I need hand-outs? Handouts with additional detail and information would be very useful to drive home my point.

Poll: What do you use for requirements management?

2006-07-16T04:08:00.000-04:00

What requirements management tool do you use and why do you use it? I've placed a poll on the right menu bar.

What do you like about it and what don't you like?

Use the right presentation style to convey your message

2006-07-15T00:12:00.000-04:00

Presentations are about selling. Whether it be a product or even an idea, you are trying to communicate your point and get people to buy-in. But sometimes your message isn't presented in a manner that connects with your audience. There are a few reasons for this:

The contents of the presentation were not suitable. As a presenter you'll notice bewildered looks, the checking of watches and the occasional sleeper. Expectations need to be set! They should be set before you even start.
Your presentation did not use an approach that related to the audience. Some people are convinced by facts, others want to know the end goal while other people want to see a plan. Know your audience!
The presentation was not structured appropriately to convey your message. Even if you follow all the tips I've previously provided, a well thought out structure will be very beneficial.

This post will deal with providing the best template for your message depending on your objective. Its inspiration was a course I attended from Bina Feldman. Some of the material is derived from her work. As such, I will only go in-depth on a few of the templates.

First what are you trying to do?

Present a solution to a problem?
Share information?
Sell a product?
Recommend an alternative?
Give bad news?

The key is to understand what you are trying to accomplish and then use a presentation template that aligns with your goal.

A template for "recommending an alternative"

For arguments sake, let's suppose you are trying to recommend one alternative versus others. A suitable presentation template would be as follows:

State the key decision.
Define the key selection criteria (e.g., "must haves" and "nice to haves.")
Rank the, "must haves." To quote George Orwell's Animal Farm, 'All animals are equal, but some animals are more equal than others.'
List the choices.
Eliminate choices that do not satisfy the, "must have," criteria.
Analyze the remaining choices against the, "nice to have," criteria.
Outline the pros and cons of each choice.
State your recommendation.

Notice the whole presentation style focuses on the recommendation and how it was reached. Everything works towards building up a strong case.

A template for "selling an idea (or product)"

State the purpose.
Outline the audience's needs.
What are the features of your idea (product)?
What are the benefits that your audience can reap?
What's the problem with the status quo? Why don't we want to do nothing?
Reconfirm the benefits.
Show how to achieve the benefits. What needs to be done to get there?
Ask for acceptance (e.g., complete the sale.)

Unlike the previous template this one focuses on illustrating the need for your idea and the benefits it provides. Create demand for your idea by stating the problems that are being faced.

Summary

I am only outlining 2 of the templates; in truth, there are many different ones (If you need some ideas feel free to contact me. Also, if you want formal training I suggest contacting Bina Feldman.)

Depending on the objective of your presentation, it is important to select a template that aligns with your goal. The use of an inappropriate template can render your presentation ineffective.

Webinar: Incorporate Real Innovation into Your Company's Business Processes

2006-07-09T13:37:00.000-04:00

Below are the details for a 1-hour webinar, sponsored by Ziff-Davis, on innovating a company's business processes. The webinar will occur on July 11, 2006 @ 2:00 p.m. Eastern/11:00 a.m. Pacific. You can sign-up for it here.

Here is the description.

Real innovation, whether it's in technology or business processes, is not just about inventing something new, but rather it requires a conscious investment strategy, and the will to carry it out. As organizations feel the effects of globalization setting in and competition heating up, companies large and small are turning to the diligent application of any number of innovation practices to try and stay ahead. Customer innovation, innovating from the edge, and innovation road maps are all well-meaning efforts to help companies with the innovation process, but without the proper focus and follow through, these efforts could be fruitless and waste employee time and company money. Innovation means little if new products and services never see the light of day. Therefore, innovation by itself is not enough, it requires an investment strategy that puts your company's resources where they count, and a people strategy that aligns those resources with the best skills of all your employees.

Join this live, eSeminar, sponsored by IBM, and hear directly from technology and business process experts on:

How to encourage an atmosphere of innovated thinking in your organization
How technology advancements can assist an organization in staying on an innovative path
Innovative ways to approach customer service to differentiate yourself from your competitors
How to put in place the business practices and processes to see innovative ideas through to fruition

Some web apps to get you going

2006-07-07T01:32:00.000-04:00

Here are some web applications that you can use to improve your productivity as a business analyst. All of these are free! But you should realize that there are some things you need to consider when using these types of products:

Confidentiality - Should business critical information be placed online?
Acceptability - Is the use of these tools acceptable to your client(s)?
Availability & recoverability - Can you get to your valued work products?

List of web apps

Gliffy - A diagramming tool that supports online collaboration. Easy to make simple process flow diagrams.
Google Notebook - A tool that allows you to make collections of information that you can arrange by subject.
Google Spreadsheets - Online spreadsheets! Not as powerful as Microsoft Excel but still useful.
Imagination Cubed - An online whiteboard where multiple people can collaboratively diagram and brainstorm ideas. Drawings can be saved and emailed.
Remember the milk - A to-do list application. You can email tasks to add to your list.
Thumbstacks.com! - A web-based presentation application.
Voo2do - A to-do list application that is suitable for project task lists.
Zohowriter - A word processing application.

Unfortunately, I have not found any free online tools that support things central to business requirements such as traceability and change request management. Perhaps that's an idea for a Web 2.0 start-up. Hmmm...

An RFI defined

2006-06-30T02:11:00.000-04:00

What is an RFI?

A request for information (RFI) is a formal request made to a vendor (or service provider) who's aim is to ascertain whether a vendor's product would be suitable for addressing a company's need.

In a previous post, I mentioned that there were a few ways to get a solution:

Leverage existing systems.
Extend existing systems.
Buy a vendor product.
Build a solution.

An RFI is used as one of the earlier phases of determining which (if any) vendor products fit; thus if you should buy it. Prior to performing an RFI, a high-level understanding of a company's needs are required as well as a short analysis of vendors who may possess suitable product offerings.

Why do we use RFIs or RFPs (Request for proposal)?

We don't need to build everything do we? Just because we can do something doesn't necessarily mean we should do something. Basic economic theory has something known as comparative advantage. This theory is usually used to describe international trade but I feel that it can be applied to many other situations.

Suppose a company has limited people resources but these resources have the expertise to develop either spreadsheet or IVR applications. Also, suppose that the company needs both of these applications but can only do one or the other. Because we know that there are suitable products that support spreadsheets, is the company better off purchasing a spreadsheet application and building their IVR applications versus attempting to build everything themselves?

Unless something is a strategic differentiator, if suitable offerings exist, you should use them. This allows you to concentrate on the activities that are key to your company.

Parts of an RFI - The introduction

Confidentiality agreement - You will be sharing information about your company that you do not want distributed to anyone else. Thus, before an RFI can be sent out, you must have a signed confidentiality agreement from prospective candidate vendors. Your company's legal team must approve both the RFI as well as provide the confidentiality agreement.
Corporate overview - This information is provided to give vendors insights and context into what your company does.
Project background - State what the project is trying to achieve as well as where you are in the process (what steps you have done or are in the process of doing.)
IT overview - Give the vendor a basic idea of the types of systems their solution will have to interact with (e.g., we have mainframes, IVR systems, we use J2EE and Oracle.)

Parts of an RFI - Description of the process

Timelines - Provide timeframes for RFI completion and evaluation.
Post RFI participation needs - State what the process will be after receiving the RFI. Will there be a need for face-to-face conversation to go into more depth? What follow-up will you want to do (e.g., reference checks & demos)?

Parts of an RFI - The questionnaire

RFI questionnaire - An elicitation of the basic requirements that need to be met. Obviously, a high-level understanding of your requirements is needed, but not a detailed one. Prematurely getting into too many details may bias your RFI and lead you towards a build mentality! Major non-functional requirements should also be stated (e.g., projected capacity, availability.)

Summary

This post is not meant to be a guide on writing an RFI but rather to give you a basic introduction to the purpose and components of one. RFI's are extremely important as they can lead to the purchase of expensive products and services. An inappropriate product choice can cause a company more harm than good.

Simple process flow diagramming - Part 2

2006-06-22T00:50:00.000-04:00

Let's expand a little on why initial process flow diagrams should be kept simple. Answer this question, "For a process, is it more important to know what or how?" The how question can lead you down a treacherous path.

Common Problems

Effort becomes focused on specific details too early in the requirement gathering process. Eventually, the prototypical, "I can't see the forest for the trees," scenario occurs.
Mysteriously, the to-be process looks eerily similar to the as-is process in terms of the different steps that are undertaken. Problems inherent in the as-is solution may still exist in the newer one. I can't tell you how many times I've encountered this problem. People are generally resistant to change. There is comfort in the familiar. Sometimes, people just don't know a better way to do something.
We end up spending excessive time defining a to-be process that restricts our thinking and may not be used. In short, we are designing a solution.

To be or not to be?

Think of it from the perspective of a company trying to come up with a solution to a problem they are facing. Ultimately, there are a few different avenues: buy, leverage (what you already have), extend (enhance what you have) or build (from scratch). If I use a complicated process to evaluate vendor products, it is very unlikely that I will find one that meets my requirements to a tee. Instead, I may conclude that, "We are unique and as such no vendor product suits our needs. Thus, we must build a solution."

Think about how many companies you've encountered in your life that were truly doing unique things and compare this to the number of companies that thought they were doing unique things. A rose is a rose is a rose.

To me, this is the worst outcome. You have already, determined your path without realizing it (you have, in effect, not been solution agnostic.)

In Conclusion

You may choose a less optimal solution path (e.g., build something that can be purchased.)
You have not used your time effectively.

These things represent inefficient use of time, resources and money. And the ultimate solution may not be as efficient as it could have been.

Simple process flow diagramming - part 1

2006-06-20T15:32:00.000-04:00

A picture says a 1,000 words... or so the saying goes, but do you really need 1,000 words to communicate a process? In truth, it depends.

Many times, on business analyst engagements, I've asked people to describe, in picture form, the basic processes that are important to their business. What I usually received was something that required a plotter to print... a huge, complicated process flow that took into account every single odd-ball anomally (even if it would only occur every 5th blue moon.) Why did this happen?

Subject-matter-experts (SME) can talk ad nauseum about what they do.
SME are detail-focused people; every detail is important to them.
SME do not like to see their business processes trivialized into one or two little boxes on a process flow diagram.

My own learning point was to find another way of getting what I needed to know rather than ask this of the SME directly. When diagramming a high-level process flow I usually follow some basic guidelines:

Identify the initiator and actors of the process.
Be technology and system agnostic.
Understand what is required to move from one part of the process flow to the next.
Show the main process flow not the alternates.
Understand the goal of the process.

The time will come when more detail is needed and the process will be flushed out. But I do not feel you have to start like that. Simple and elegant always win out.

Online webinar for requirements management

2006-06-14T00:23:00.000-04:00

There is a webinar coming up on June 21, 2006 entitled, Requirements Management: Best practices for enhancing project success. Follow this link to register for it.
Here's a brief description directly from BZmedia, Get to the bottom of the prime reason for project failure--poor or incomplete requirements capture and management. Geared to project managers, business analysts, architects, developers and QA/testers, this session will highlight the benefits of structured requirements with SteelTrace to all stakeholders.

How are your business analysts doing?

2006-06-09T14:36:00.000-04:00

How do you determine how well your business analysts are performing?

There are a few different aspects that can be used to measure your business analysts. When I say measure I mean from the perspective of areas for improvement and to understand the strengths and weaknesses of individual analysts.

Deliverable quality
I already wrote about how to assess requirement quality. Use requirement clarity, completeness, consistency, testability, traceability, modularity, feasibility, design independence and correctness to assess the quality of the deliverables.
Meeting expectations
As part of any engagement, a business analyst needs to set expectations regarding the deliverables.

What are the work products to be delivered?
What tools and applications will be used?
What is the estimated time required to complete the deliverables?
Who needs to be included in the process?

Basically this amounts to a business analyst following through on what they said. However, some leeway is needed to allow for the use of different approaches when the situation warrants it. Flexibility is important afterall.

Soft skills

Professionalism and conduct
Development of relationships
Facilitating understanding across the business and IT teams.

Conclusion
Ultimately, the outcome of a project determines its success. When looking at the business analysts involved you can measure them based on three basic areas:

Quality: Quality of deliverables
Time: Meeting of expectations
Resources: Facilitating understanding, development of relationships and professional conduct.

Assessing requirement quality

2006-06-05T19:08:00.000-04:00

How do you assess the quality of your requirements? We know that requirements change over time. We know that sometimes we are working on projects in areas where we are not subject matter experts. We know that there can be many unknown unknowns. So how do we know we have a solid set of requirements?

A while ago I posted a series on characteristics of good requirements. These characteristics can be used as measurement criteria for quality.

Items to consider:

Clarity - You should be able to provide your requirements to an uninvolved third party and they should be able to understand what you're trying to say.

Is there a lot of jargon being used?
Is the language used simple and concise?
Can alternative meanings be derived (e.g., ambiguity)?

Completeness - Understanding whether a body of work is complete may be a little tricky. If there are common industry models that relate to your project compare and contrast them with what you have. Gaps may emerge that indicate missing requirements.

Do the requirements provide a sufficient level of detail and understanding to the business need?
Do you understand the context and how groups of requirements fit in with the entire body of work?

Consistency - Inconsistent messages are like bad driving directions, you may never get to where you wanted to be.

Are there contradictions in the requirements?
Is the terminology used consistent in it's meaning?

Testability - Requirements must be determined to be fulfilled or not.

Is there a way to test the requirement? Are there proxy tests?
Are there many requirements joined together (e.g., the word "and" is used often)?

Traceability - You can trace forwards and backwards and prove that your needs are being accounted for.

Can you determine which high-level requirement a low-level one belongs to?
Can you determine what are the higher-level requirements that lead to a low-level one?

Modularity - Making changes as simple as possible.

If you have to make a change, do you only need to make it in one place or must you correct many different places in the document?

Feasibility - Add a touch of realism. If you are a marketing company, it is probably not feasible for your team to design a rocket ship.

How realistic are the requirements based on your understanding of the client's goals, objectives and capabilities?
Is it even possible to do what is being asked?

Design Independence - Requirements should be agnostic of technology and speak only of business need.

Do the requirements answer the "what" questions or the "how" questions?
Are the requirements trying to fix a problem with an existing system rather than defining a business need?

Correctness - Everything must be in accordance with legislation and client guidelines.

Is everything legal? What guidelines or legislation must be followed?
Is everything ethical?

Epilogue

When examining requirements documentation these questions can help you get a grasp on the quality of the requirements. High quality requirements contribute significantly to better products. A previous post, Why you need good requirements, explained the rationale for wanting solid documentation and the potential consequences of poor requirements.

Improving clarity in communications

2006-05-31T00:03:00.000-04:00

One of the most important skills you can master is to be able to communicate effectively and efficiently. In the past I wrote a few pieces on improving clarity for requirements and presentations:

I've decided to summarize the main points from these three posts into a presentation deck. As usual I've uploaded the deck to esnips.com so please feel free to access it (I've used high quality images so the file is on the large size.) The file is called, Clarity, and you can access it here. As always, any feedback is greatly appreciated.

The ignored step-child - the non-functional requirement

2006-05-27T23:39:00.000-04:00

There have been some very interesting posts on non-functional requirements taking place recently.

About a week ago I posted, an item called Non-functional requirements & QA test strategies that was based on a comment received my leathej1 for my non-functional index as well a link to his post, The Fallacy of Non-Functional Requirements. The thrust of leathej1's idea was that non-functional requirements need to be collected in the same manner as functional requirements. This concept comes from his experience in quality assurance; where response times and performance targets are important to a system's acceptance. He made an excellent point that these sorts of items are usually given little consideration.
As a follow-up to leathej1's post, Scott Sehlhorst put up an article called, Non-Functional Requirements Equal Rights Amendments. Scott proposed a different way of looking at functional and non-functional requirements.

Read these articles, they're excellent.

Why you need good requirements

2006-05-23T00:28:00.000-04:00

Why are requirements important to a project? The answer may seem trivial but let's look at some empirical evidence.

According to the Standish Group's chaos report (1995), only 16.2% of software projects are completed on-time and on-budget.
The KPMG Canada Survey (1997) stated that over 61% of projects were deemed to have failed.
According to Forrester Research, "No single factor is responsible for more wasted effort, rework, or failed projects than inadequate requirements (Carl Zetie.)"
Borland recently posted a new press release for Caliber DefineIT in which they state, "Analysts ... cite inaccurate, incomplete and mismanaged requirements as the number one reason for software project failure. The Standish Group's annual CHAOS report indicates three of the top five reasons for project failure are related to requirements. In addition, requirements errors are a primary factor behind most rework efforts, which ... can add up to 40 percent of the total development effort within a given project."

Let's also consider trends in business.

We are dealing with more complex systems.
We need to move faster because the business environment is changing faster. We need to react more quickly.
Project teams are moving towards more people-oriented development paradigms (e.g., Agile.)

What does this all mean? Successfully delivering projects (e.g., on-time and on-budget) is a difficult task. Furthermore, the environment is evolving and becoming more complex than ever, making a difficult task more even difficult.

I remember talking to a small group of business folk about requirements management practices and its importance (I've uploaded a variant of the presentation I used, titled The Need For Requirements.) It was very encouraging to watch the expressions of the different individuals as we went through the conversation and they started to appreciate the complexity of a project and their role. Understanding is step one.

Online folder for file sharing

2006-05-21T12:47:00.000-04:00

One idea I've been toying with is the proliferation of materials I've used to foster more understanding and learning for others as well as myself. To this end, I've added a new icon on my menu bar.

If you press it you'll be directed to the esnips.com folder for this blog where you can get access to some of the slides and presentation material I have created. Feel free to use the material, I only ask that you credit where appropriate. One thing to note, as you look at the presentations, they are done in a very visual style. There is a bit of information on the notes pages to provide context to the presentations; so I suggest you look at them.

I've been writing a lot about presentation skills and requirements, so this is your chance to see how well I, "walk the talk." If you have any comments or feedback I'd love to hear it.

Slides available: Testing & validation

2006-05-20T02:16:00.000-04:00

The slide I used on my post, Testing & validation, is available for download at esnips.com. You can find it using this link.

Slides available: The project and the business analyst

2006-05-19T23:45:00.000-04:00

I've been running around giving a lot of presentations recently. I'm going to start making some parts of them available for interested people. Please feel free to provide any feedback you may have on either the content or my slide design. I don't mind if you distribute them, but I ask that you credit appropriately. Thanks!

The first set of slides I'm making available were used on my post, The project and the business analyst. You can find them on esnips.com using this link.

Non-functional requirements & QA test strategies

2006-05-18T21:54:00.000-04:00

I received an interesting comment on my index post for non-functional requirements, from leathej1. Below is a short clip.

I just posted something on my site that has been gnawing at me for a few years - the fact that in my mind there is no such thing as a non-functional requirement. As defined in the traditional RUP sense.

A link was provided to leathej1's blog that contained his rationale. I'm still mulling it over in my mind but his post called, The Fallacy of Non-Functional Requirements, contains an excellent QA test strategy covering off the testing of "non-functional" requirements. I encourage you to visit his blog and check it out.

The 4 P's plus 1 reloaded

2006-05-14T22:54:00.000-04:00

Back in January, I outlined the basic 4 P's of marketing in my post, Marketing basics - the 4 P's. As a recap, the 4 P's (plus 1) of traditional marketing are:

Product - The offering be it a physical product, service or combination of the two.
Place - The method of distribution (e.g., physical storefront, online.)
Promotion - The strategy and messages comprising the communication aspects of marketing the product.
Price - The pricing strategy utilized. This includes discounts and product bundling.
Positioning (the last P) - How a product or company is perceived in the marketplace.

I came across a post called Marketing Remix, by John Sviokla, that provided a new 4 P's (err... plus 1!) It's an excellent read and demonstrates how marketing is shifting from the traditional view to a newer paradigm. To paraphrase (as well as add some of my own thoughts):

Product becomes Personalization - Standardized products are giving way to more customizable offerings composed of physical products and the services associated with them.
Place becomes Presence - The main argument on this piece is that there is much more than just a physical storefront. People can augment everything with simple web searches for more information. The main business concern translates to having a presence where people gather their information and make their decisions.
Promotion becomes Persuasion - Sending out traditional advertising is a big item in promotion. However, notice the trend towards the proliferation of user reviews (and other social mediums that are not controlled by marketers) for products.
Price (static) becomes Price (dynamic) - With the availability of information there is a greater ability to do direct price comparisons between products and retailers. Bundling, in-the-moment discounts and specials mean pricing strategies are more dynamic.
Positioning becomes Preference - Preferences can be interpreted based on things a consumer says, through analysis of their past purchases, through analysis of their search (information gathering) behavior and finally from configuration tools that they use (e.g., a design your own car tool from Volkswagen.)

Please go read John Sviokla's post. It's an excellent read for new age marketing.

INDEX for business analysis

2006-05-12T22:11:00.000-04:00

Starting out:

First things first; learn the skill: Understand how to structure and write requirements before you start using requirements management tools.
Asking questions and getting answers: Learn how to ask questions to get answers to the important issues.
Why you need good requirements: Some quick facts on project success and requirements. Presentation available.

Requirements:

What are requirements?: A quick definition.
Correctness: There are some things you just can not do.
Completeness: Make sure that all of the, "what," questions are answered.

Clarity: Requirements should be succinctly stated; using as few words as possible. Otherwise, ambiguity may occur. Excessive rambling, jargon & wishful thinking confuse readers -- avoid it. So it's still not clear?! Here's a short presentation deck recapping all of these items (the presentation is simply called Clarity.)
Consistency: I hate it when people say, "Turn right. Your other right!"
Testability: Prove to your client that the solution meets their needs. When a statement contains multiple requirements it's testability can be compromised.
Traceability: What requirement led us to do this? How much work do we have left?
Modularity: Update in one place and only in one place. Makes change management a lot less painful.
Feasibility: Do you really think with enough time and money you can solve any problem?
Design Independence: It starts with what and why. How comes later.
Requirements vs. requirements management: Gathering requirements and managing them.
Assessing requirement quality: How do you know if you have decent requirements?

The why of business analysis:

The business analyst & the business systems analyst: What's the difference?
The why of business analysis: What purpose and role do business analysts serve?

Running a business analysis engagement:

Prepare thyself - make sure it's not you: Make sure you're mentally and psychologically ready and able to work. Eliminate any preconceived judgments and notions.
Know the situation: Before you start an engagement take some time to grasp the nature of the project, it's urgency and the resources you'll need.
Choose your tools: Decide what approach you will use. Will you prototype, interview, brainstorm or observe behavior?
Set expectations: Ensure your role on the project is clearly defined and that you understand the roles of others as well.
Time estimation: Estimate how long it will take you to complete your tasks. As you run through more projects your estimation skills will increase.
It's the little things... Words that should make your ears perk up: Little words that your clients say that create headaches for you unless you clear them up now!
New! How are your business analysts doing? Understand how to assess them.
New! Understanding the goal: Knowing the objectives of your requirements gathering sessions helps you determine whether the requirements you are getting will actual help to solve the problem.

Project Bits & Bites

How do you know you're done?: Use requirements management practices and traceability to see how much work you've done and how much you have left to do.
Well-done or done well?: Use cost-benefit to determining where to invest your energy.
System development life cycles & requirements: A very high-level overview of different system development life cycles and how this impacts requirements gathering.
The project and the business analyst: Understand your role in a project and the activities you'll perform to support the initiative. Slides available!
The sweet smell of success: Measuring success on a project ultimately boils down to meeting or exceeding targets established earlier in the project.
Choose a methodology that suits your project: No one methodology will fit all projects.
Testing & Validation: What are the different types of testing that occur as a project moves forth? Slides available!
New! Requirements in an agile world: Understand that impact a different project methodology will have on requirements.
New! Setting expectations: It's important that people know what you are delivering and why.
New! How a "bad" requirement can stifle innovation: A lack of design independence in requirements can lead to a sub-optimal solution.

Non-function requirements: Upgradeability

2006-05-11T00:29:00.000-04:00

It's been a while since I last posted on non-functional requirements so I'm going to ease my way in with a simple one, upgradeability. This characteristic defines the ease at which components of a system (e.g., software) can be replaced with newer pieces with minimal changes to the rest of the solution.

Let's use some examples to demonstrate this non-functional requirement. Suppose your system uses a service-oriented architecture approach (you can find lots of information on SOA at ebizq.) Your system handles purchase orders from a web site, calculates taxes and then sends out orders to your fulfillment group. If the tax rules change, you can build or purchase a replacement component to handle the tax calculations. Components are loosely-coupled in a service-oriented architecture, thus changes to one component are transparent to other components (as long as the service itself functions the same way.) In this case, the upgradeability of the system is high.
On the otherhand, suppose you purchased an accounting system and built a lot of direct interfaces (e.g., tightly-coupled) to different applications to provide information to it. Now, a newer version of the accounting program is released that uses XML to transfer data around. The custom interfaces and other custom work will have to be examined to see whether they will still be able to function. There is a high probability that you will need to rework or rebuild a significant amount of them. As such, you would say the upgradeability of the system is low.

In general, tightly-coupled systems and systems with high levels of customization are more difficult to upgrade.

A breakaway innovation

2006-05-08T19:06:00.000-04:00

Time magazine has an interesting article called, A Game For All Ages (by Lev Grossman), which provides a hands-on preview of the new Nintendo Wii video game system. The control system used for this game platform would qualify as revolutionary (see an earlier post Types of innovation) as it incorporates motion sensing technologies into a controller that resembles a remote control (something a lot of us are too familiar with.) It has potential to change the way people play games since a different level of interaction can be used (see the article for details.) Of course, it remains to be seen how well this translates into profit.

In the article, there were two very interesting comments that stuck out to me:

If you are simply listening to requests from the customer, you can satisfy their needs, but you can never surprise them.

It is definitely more difficult to come up with revolutionary ideas. When listening to your customers, you'll hear more along the lines of the tried-and-true with some new bells and whistles. On the otherhand, you can't ignore your customers either.

Cutting-edge design has become more important than cutting-edge technology.

The overall experience of using a product or service is the new paradigm. Simplicity of design and usability are key factors for success and product adoption. Think of why the Apple Ipod has been so much more successful than any of its competitors.

INDEX for presentation skills

2006-05-07T22:42:00.000-04:00

This is an INDEX for my presentation skills postings. As new items are added I will include them in the list below. I'll make sure that this post stays near the top of my popular list. Remember, presentations are about communication. Communication is about getting people to understand and buy-in to your ideas.

The picture above is from Apple's 1984 Superbowl commercial.

Communication from the pros - This post is based on two articles: How to Wow 'Em Like Steve Jobs (by Carmine Gallo) and Speech Writing Secrets of President Bill Clinton (by Tomas Murrell.) It covers the styles of two of the foremost communicators.

*NEW* Use the right presentation style to convey your message - Depending on the objective of your presentation, it is important to select a template that aligns with your goal. The use of an inappropriate template can render your presentation ineffective.

*NEW* Improving clarity in communications - A short presentation deck providing some tips and common sources of ambiguity. You can find the deck (called Clarity) in my esnips.com folder.

Give each of them something - Some people want to see a plan. Others will listen to you after you've established a relationship with them. Still others will want to know your goals; they'll figure out their own way to get there. This post speaks on how to communicate with these different types of individuals.

Some more presentation tips - General tips for improving your presentations such as stopping side-conversations, using active listening techniques to respond to questions and using physical presentation aids.

Some tips on presentations - This post is one of the more popular ones on my blog. The basic parts are the pre-planning, slide design principles, and other prep activities that will help you make & deliver great presentations.

The soft-side of presentations - This post provides tips on the delivery aspect of a presentation rather than slide design. These tips include how to use gestures, to speak more slowly than conversation speed, and to change the pace of your presentation every 15 minutes or so (the average attention span.) A good PowerPoint deck won't mean anything if you can't sell your ideas.

Other resources & tips for presentations - Online resources for improving your presentation skills.

A walkthrough of the process I followed to make a presentation

*NEW* Building a presentation - Part 1 - Who is the presentation for? Initial planning...
*NEW* Building a presentation - Part 2 - Do a little digging to find clues that will help you make a more effective presentation.
*NEW* Building a presentation - Part 3 - Assemble your material and choose an appropriate template to communicate.
*NEW* Building a presentation - Part 4 - Version 1.0 is ready for a mock-run.
*NEW* Building a presentation - Part 5 - A short run-through to make sure I'm on track.
*NEW* Building a presentation - Part 6 - The morning after... Assessing how your presentation went.

How to listen and hear nothing at all

2006-05-07T02:14:00.000-04:00

Courage is what it takes to stand up and speak; courage is also what it takes to sit down and listen. (Winston Churchill)

This post extends upon a previous post (Make sure it's not you) covering the topic of listening skills. More specifically, how to identify when you are listening but not actually hearing what people are saying. I strongly believe that listening (recognizing the words) and hearing (thinking & understanding) what people say are two entirely different things.

For example, you can introduce prejudices that influence how you interpret the actions and words of another person in either a good or negative fashion. However, you are introducing distortion and potentially negatively affecting your relationship by doing this. Suppose, I listen to you with rose-colored glasses (e.g., I take everything in a positive light), I may not realize I need to deliver a strong message to you such as, "I don't think that idea will work because it does not address your core need." On the other hand, I don't think you'd like it if I merely gave you lip service and didn't even consider your arguments seriously. So how can you tell if you aren't hearing what people are saying? Here are some indications:

Are you constantly interrupting people? Do you finish their sentences?
Are you unwilling to even listen to anything that doesn't fit with your thinking?
Do you think the issues facing others are trivial before you even speak to them?
Do you feel you know what people need before they even discuss it with you?
Do you roll your eyes when others are talking to you?
Do you enter a conversation with a preset position? Does this position distort what you hear?
Do you start side-conversations with other people rather than always being attentive to the speaker?

These types of behaviors can be indicative of a listening (I mean hearing) problem. The hardest part is realizing that you are listening but not hearing. However, you can resolve this problem with a few simple steps:

Before you enter a discussion, divest yourself of any preconceived judgments and notions.
Let people talk to you in their own words. Don't put words in their mouths or lead them.
Use active listening to play back what you understood. Clarify any miscommunications.
Ask probing questions to fill in the gaps.

After taking these simple steps you'll have a more unbiased and objective perspective. Furthermore, your clients will know you're listening and interacting with them.

INDEX for non-functional requirements

2006-05-04T18:12:00.000-04:00

I talked to Scott at Tyner Blain about my non-functional requirements series and he suggested that I create an index for them. As I add new posts, I'll add them to this list and make sure the index appears in the Popular posts section.

Complete list of non-functional requirements
This is a very early post containing the names of the different types of non-functional requirements. No details provided but a good starting point.

Availability
There are two key concepts for availability: Hours of operation and reliability. The first refers to what times a system will be available for production. The second refers to it's availability during the stated hours of operation. I supplemented this post with the following one, Extreme availability & reliability.

Capacity
Capacity deals with the projected load that a system will handle. This includes its growth and the timing around when heavy load conditions will occur. As companies move towards a more service oriented architecture approach it becomes very important to be able to understand capacity.

Data currency
How up-to-date does your information need to be? Do you need real-time or are delays acceptable? Data warehouses generally operate a few days or weeks behind. For general reporting needs, this situation is acceptable.

Data retention
Address your needs to store and dispose of information. There are industries which have legislation surrounding the acquisition and disposal of information. Recognize that some types of data become useless as time passes.

Disaster recovery
This non-functional requirement relates to a business' needs for a system to recover from an outage. How important is the system and how quickly does it need to be returned to production?

Error-handling
Describes a system's ability to handle unexpected situations such as purchase orders for unrecognized products. How should you account for these transactions?

Internationalization
This is an important characteristic for applications that will operate in multiple geographic regions, currencies, tax regimes and languages.

Logging
A system's ability to keep track of its activity. This provides an audit trail that can be used for problem-solving.

Security
Describes how a system handles customer privacy as well as user privileges.

*NEW* Upgradeability
This characteristic describes the ease of replacing a component in a system with another one.

*NEW* The ignored step-child - the non-functional requirement
Links to an important conversation on the importance of non-functional requirements and their neglect.

The strangest things

2006-05-02T22:19:00.000-04:00

Sometimes as a business analyst you'll hear some of the strangest requests. Things that will make you do a double take. "Excuse me, did you just say...?"

Some of the most odd requests I've heard are:

"I want you to put a little lightning bolt in the top right corner of the screen that indicates the application is still processing." At the time we were working on a web-based application, so we asked, "You mean like the little symbol that twirls in the browser?"
"In the older application, when I hit the ENTER button it tabbed to the next field. I want the new web-based version to do that as well." Of course my web developer looked at me incredulously and proclaimed, "I didn't build the damn thing (the browser!) So if ENTER is pressed to tab, what is the TAB button for?"
"I want you to run a pharmaceutical patient compliance program. We get the pharmacists to contact the patients and talk to them about the importance of refilling their medications. Oh yes, because of privacy concerns we cannot identify the individuals. You'll get an unique index for each person, but it is only unique within the same store." Needless to say at the end of the day, our data was very useless.

The important thing is how would you handle these requests?

Suppress the urge to laugh out loud no matter how funny you think it is.
Make sure it's not you! Make sure you're listening properly.
Use active-listening techniques to see if that's actually what your client meant. Remember your objective is to foster understanding.
Your client has told you what they want. Make sure you ask, "Why do you want it?" What is the business justification?

The greatest ignorance is to reject something you know nothing about.

A practical guide to communication

2006-05-01T00:53:00.000-04:00

When you are explaining something to someone, you may use a different approach based on your understanding of the other party's background, knowledge and areas of concern. Messages that work well for one person will be poorly received by others. The reason for this is simple, you need to be able to communicate to someone in a manner that resonates with them (see my earlier post, The why of business analysis.)

How does this play out in the real-world? Suppose you applied a patch to a database but something went horribly wrong (for the sake of simplicity let's assume there aren't any redundant systems) and the database is not longer available. Also, let's assume this database provided product information that was consumed by your website, IVR and agents. How would you express the problem?

When talking to the technical support staff, you may mention that the patch has brought the system down. Next steps may be to inform your clients of the outage, roll-back the patch, get the database operational and then contact the database vendor for support.
Now suppose you are talking to the business side, how would you express this outage? Would you use the exact same language? Probably not. The questions that interest the business are:

What is the impact of the outage? Explain which systems are impacted and the extent to which they are impacted (e.g., It's taking the servers 3 times as long to respond.)
How long will the outage last? How much money is this costing me? The system will be fully operational at ... In terms of lost sales opportunities, during that amount of time we would normally have 800 sales transactions.
What can I do in the meantime? How can I help? Direct your consumers to use alternative channels or to contact you a little later.

Note the drastic difference in the responses between the technical and business people. Business users are very interested in the, "So what?" types of questions, not the details. When explaining something to people, put yourself in their shoes. What would they want to know?

Non-functional requirements: Logging

2006-04-28T20:22:00.000-04:00

Understanding what activities are processed through a system is critical to knowing whether it is behaving as expected and central to diagnosing potential problems and issues. The key benefits of logging and tracking are:

Facilitates problem-solving. Should an unexpected result be produced, you can follow a transaction through the system to identify where a problem starts.
Provides transparency into the operations of a system. In turn, this proves reliability and predictability.
A log provides an audit trail. Logs can be used to detect patterns in behavior as well as find inappropriate user activities. For example, you may notice 5 different transactions for completely unrelated people, however, the delivery address is the same. This could indicate potential fraud. If the transactions were examined individually, this form of fraud may go unnoticed.

Considerations for determining the extent of logging for a system include:

The length of time that you will need logs (see my post on Data Retention.)
Capture appropriate information to support problem-solving and investigation into normal transactions as well as exceptions (see my post on Exception Handling.) To keep track of a purchase order without the details (such as the products and prices) may not provide enough information to support further problem-solving or generate insight.
Are there legislative reasons why you need to track specific types of information? In the United States there are efforts underway to force ISP to log the activities of their clients.

As you can see, data retention, exception handling and logging are closely intertwined.

Non-functional requirements: Error Handling

2006-04-27T21:54:00.000-04:00

How should a system handle the unexpected? This is a fundamental consideration of any solution.Key points to keep in mind are:

What are the consequences of not resolving errors? If you are working on a financial system, a missing transaction means that account reconciliations will be difficult, or in other words, you are misplacing money! In such cases, you should consider creating suspense accounts to hold the erroneous transactions. Operational staff can then balance the suspense accounts to zero and route the corrected transactions appropriately. Common types of errors include invalid accounts and invalid products. Keep in mind that you may encounter errors that you never considered.
Will you process batch or real-time transactions? Do you foresee needing to reverse out large numbers of transactions to remove erroneous transmissions? Should you submit reversing entries or delete all of the errors? When you load transactions, make sure you include the appropriate information to allow you to identify the record or group of records.
What will you do to prevent the loading of problematic transactions? Do you need to quality control (QC) the transactions and then reject them if they appear erroneous? For a batch, if more than a specific percentage have errors the batch may be rejected completely. Conducting a few simple QC tests will keep you from going through the pain of fixing transactions that have made it into your system.
Should you keep record of the original transactions that have been processed? Is error logging required?

For many systems, particularly financial ones, losing a transaction is a faux pas. If your system does this, its reliability may be questioned.

Non-functional requirements: Data Retention

2006-04-25T00:42:00.000-04:00

Data retention refers to the storage of a system's information for a specified period of time. This information should be examined according to the different data domains (e.g., transactional, consumer, product, complaints, etc...) Each domain may have separate retention requirements. For example, information on products and transactions may be stored indefinitely, however, consumer records maybe be purged after 4 years of inactivity.

Considerations for data retention include:

System - What are the uses of the information? Will you be doing long-term trend analyses or operational reporting only?
Legislative Restrictions - Some information sets may have legislation concerning their mandatory disposal after a specified elapsed time. Other places have legislation mandating data retention for specific industries (e.g., Europe has legislation mandating data retention for telecommunications firms as part of their anti-terrorist activities.)
Useful Life - How old can information get before it becomes dated? For example, marketing information that is 12 years old probably has little value to marketers. Because you were a student 12 years ago probably does not help a marketer that much now.
Customer Service - How much historical information on a client is required to deliver appropriate levels of service?
Data Aggregation - Should old information that is being disposed of be rolled-up so that long-term trend reporting can take place? Do you ever anticipate looking at the detailed information again?
Data Disposal - Should old information be kept offline or removed permanently? What type of archiving is necessary?

Based on your needs, your data retention strategy may require additional capacity and storage facilities. All of this comes at a price. As such, you must be careful to balance your desire to retain data with the cost of its maintenance.

Non-functional requirements: Security

2006-04-23T20:25:00.000-04:00

One of the most important non-functional requirements is security. Security requirements can come in many different forms:

Privacy - Requirements can dictate protection for sensitive information. Some types of privacy requirements include: data encryption for database tables, policies regarding the transmission of data to 3rd parties (e.g., scrambling user account numbers), etc... Sources for privacy requirements could be legislative or corporate.
Physical - These requirements relate to the the physical protection of the system. Other types of physical requirements include items such as elevated floors (for server cooling), fire prevention systems, etc...
Access - Access requirements define account types / groups and their access rights. An example of an access requirements could be to limit each account to one login at a time or to restrict where an application can be deployed or used.

While most clients can tell you what availability or capacity they expect to need, it is less likely they may know everything about the security aspects. As such, I suggest you ask security specialists for their advice and opinions. The Journal of Object Technology has a great article on Engineering Security Requirements by Donald G. Firesmith. I suggest you look there for a more complete look at security.

Extreme availability & reliability test

2006-04-21T23:36:00.000-04:00

Earlier in the week, I wrote about Availability and Reliability. Yesterday on Digg.com there was an interesting post showing an HP StorageWorks XP12000 Disk Array performing under load during the process of having a bullet fired through it.
The test showed a high-caliber round being fired through the disk array and through a fish tank on the other side. The disk array was streaming video to many monitors in the room. The goal of the test was to see whether the video would be interrupted. The results? You can watch it here! Keep in mind that the video is a marketing promotion but the test itself is very interesting and clearly shows extreme availability and reliability testing.

Interesting thought: Is your company dead in the water if someone shoots your server?

Non-functional requirements: Data Currency & Internationalization

2006-04-19T23:38:00.000-04:00

This is my third post on non-functional requirements. Let me reiterate that non-functional requirements describe characteristics of a system as opposed to how a system functions or operates.

Data Currency
Many systems collect data and provide data for users. Data currency, refers to how up-to-date this information is. Trading systems require access to real-time information or their business value is negligible. If you were a day-trader, would you be willing to use yesterday's prices to execute your trades?

Other types of systems do not have as stringent requirements (e.g., data warehouses.) Data currency can affect your choice of solutions to a business problem in that if real-time information access is required, specific procedures such as batch uploads cannot be utilized.

Internationalization
Implications could be the need to have multi-language descriptions of products as well as pricing schemes for different currencies. Web sites such as ebay have regionalized sites where prices are displayed in a user's native currency. In general, internationalization focuses on the countries, time-zones, currencies and languages that will be supported.

The proliferation of web applications is pushing us towards a more global view. Today you may only have to deal with 2 languages, but tomorrow it could be 3, 4, 5 or more!

Non-functional requirements: Disaster Recovery

2006-04-16T23:07:00.000-04:00

One thing that was implied in my previous post, Availability & Capacity, was that higher levels of reliability are costly. Costly because it implies redundancy and ensuring there are no single points of failure.

Another, expensive non-functional requirement is disaster recovery or recoverability. Disaster recovery considerations should be made for every application. However, I'm not sure I could say they are taken into account appropriately. It's like the unwanted step-child from fairy tales of old that no one wants to have anything to do with...

Items that must be taken into consideration are:

System criticality - How important is a system to your company? Real-time trading systems are more important than intranet applications; at least for most companies.
System recoverability - How fast must you be able to restore full or partial service (in minutes, hours, days, weeks, etc...)? A system's criticality will help answer this question.
Magnitude - What is the scope and scale of outage that you are willing to deal with? Two of the companies I worked at in the past had disaster recovery facilities approximately 10 kilometers from their main facilities. This was great for testing the facilities and made it easy to transport designated workers to the alternate locations. Now suppose there was another blackout like the one in 2003 that hit the Eastern coast of North America. There would be no way that geographically close disaster recovery centers would be able to function. Notice the nice black area where Toronto, Canada and New York City are. Consumers inside that area would not be able to buy things from our e-commerce sites, however, what if the majority of our consumers are not in affected areas?
Disaster simulation - You'll need to practice how you would operate during a disaster. Simulate a disaster and then see what problems you encounter. This is how you find out silly things such as your servers are working fine but there is no internet access so you're offline and inaccessible.

Disaster recovery is really a business decision and it should be treated as one. What risk are you willing to accept and live with?

Non-functional requirements: Availability & Capacity

2006-04-16T00:43:00.000-04:00

I've spent a bit of time writing on basic presentation, communication and innovation themes. Now I'm going to refocus and go into more detail on one of my earliest posts titled, What are requirements? SDLC? More specifically, I am going to expand my coverage of non-functional requirements and their implications.

Non-functional requirements govern characteristics of a system. Many non-functional requirements will have direct implications to a project in the form of cost implications, performance objectives and future growth potential.

Availability
Availability indicates when a system is operational as well as how reliable it is during operational periods.

Hours of operation - What are the hours that a given system will be available? What days will the system be operational? Not all systems operate on a 24/7 basis. Some internal facing systems may only be needed when there are people in place to operate them.
Reliability - During a system's hours of operation, what reliability (excluding planned outages) is needed? Reliability is usually measured as a percentage. The higher the number, the greater the cost. Many people ask for 99% reliability but do you actually need it? 37signals has a great post explaining this concept. The question to ask your clients is, "What level of reliability is justifiable from a business perspective?" Will the world end if your web site goes down unexpectedly for an hour? The answer will be different for different systems and companies.

Look at the picture below to see what are the allowable outages based on the level of reliability required.

Capacity
The ability to handle transactional volumes is a very important characteristic for a system. If you are building a high-volume e-commerce web site but you can only support 10 concurrent logins, you've got a major bottleneck. Here are a few considerations you will have to take into account:

What are the different types of things (e.g., types of supported activities or transactions) that can happen?
For each type of transaction, what volumes do you see on an hourly, daily, weekly, monthly etc... basis?
What types of patterns exist for the transactions? Are volumes significantly higher during specific parts of the day (e.g., at lunch), week, month or year?
What transaction volume growth are you expecting?
Will additional systems make use of the services you are building? You may have taken into consideration your website's needs, but what happens when the point-of-sale systems start trying to use your services? Can you manage this additional volume?

Summary
Non-functional requirements such as availability and capacity can have substantial cost implications to a project. Almost everyone wants 24/7 hours of operation with 99.999% uptime and the ability to process thousands and thousands of transactions. However, does that meet the cost-benefit test?

Big and small

2006-04-11T19:29:00.000-04:00

Innovations can come in all sizes: big or small. Look at the little innovation square from my post, Types of innovation. They don't have to be earth-shattering or the next big thing. Innovation can be as simple as trying to improve performance and improving the quality of one's life.

Where do you go for inspiration?
To the competition - What do your competitors do? How do they handle the problems you face? How can you improve upon their offerings? Look at the Apple Ipod. Prior to its introduction there were MP3 players already in the marketplace (e.g., the Eiger Labs MPMan F10.) What separated the Ipod from the others was it's ease-of-use, design and quality.

From unrelated companies - Companies in different industries can face similar problems. Learn from their experiences and mistakes.

From within - Think about the unique capabilities of your company. How can you leverage them to obtain more benefit from your investments? Perhaps your organization is a pioneer and has knowledge others do not (unlikely but this can happen)?

By accident - Research scientist Dr. Spence Silver was trying to develop an adhesive. However, his work yielded an adhesive that could be peeled off over and over. Art Fry realized he could use this adhesive to keep his bookmarks from falling out of his books. Hence the 3M Post-it Note was born!

Use something in a different way - Thomas Savery designed a steam engine to pump water out of mine shafts. Charles Parsons later used the same concept for marine vehicle propulsion and as a means to generate electricity.

Inspiration can be found everywhere!

Questions lead to innovation

2006-04-10T19:03:00.000-04:00

By nature, people do not like change. They develop comfort with routine, regardless of whether it makes sense or not. It's some sort of inertia.

As a business analyst you will encounter this inertia many times. Where you'll really notice it is when you are trying to redefine a process to be more efficient and realize that the new process is strikingly similar to the old one. When you ask them why the new process looks the same as the old one, you'll hear answers such as:

"I don't know."
"We've always done it that way."
"I'm not sure why we do that; we just do."
"Why would I do it anyway else?"

With any process, you should try to understand why you need to do any specific step. What are the key benefits, considerations, safeguards etc...? Are we simply asking for a step in the process because, "it's always been there?"

Be willing to inquire. Of course you'll need to be a little careful to avoid offending people (see my post Asking questions & getting answers.) However, you must understand your clients' wants in order to determine the best ways to achieve it. As a business analyst, you have a few objectives:

Understand your clients' desires.
Communicate the needs so that IT staff can understand them.
Analyze and innovate to make things better. This is where you add additional value to a project. I'm not talking about increasing scope with all of your ideas. I mean, add value to help your clients' maximize the benefits they can realize.

Is there a better way to do something? What can we learn from other industries? What can we learn from other companies? What can we leverage more?

A company's ability to innovate, improve, and learn ties directly to the company's value. (David P. Norton)

Communication from the pros

2006-04-07T17:14:00.000-04:00

This post outlines key observations on the presentation techniques of two of the best known presenters, Steve Jobs and Bill Clinton. Without further ado...

Steve Jobs' Tips:

BusinessWeek has a great article, How to Wow 'Em Like Steve Jobs (by Carmine Gallo), that talks about Mr. Jobs legendary presentation skills. The key points are:

Sell the benefit - Talk about how this will make things better for people by enhancing their lives. What does it mean to them? Don't say things like, "We have redundant server clusters around the globe." Instead try this, "Our 'doors' are always open for business. When a server goes down, our consumers can still interact with us and purchase our products."
Practice (a lot) - If you want to come across naturally, you must be intimately familiar with your material. You are rehearsing your presentation. It's got to be an event people want to attend, not a chore they have to do.
Keep it visual - Use good, simple pictures and words instead of data driven slides. Eventually all the numbers will blur into something incomprehensible to your audience. Use too much data and you'll soon hear the sound of snoring.
Exude passion - If you don't show genuine interest & excitement in your subject why should anyone else?
"And one more thing..." - Close strong. Give them something else. This is the marketing WOW factor.

Bill Clinton's Tips:

On Ezine Articles there was a great write-up by Tomas Murrell on Bill Clinton's speechwriting ability. Mr. Clinton is widely regarded as one of the best speakers on the planet. One of the comments about Mr. Clinton's speeches is that he gives everyone something that resonates with them. This is a great article so please read it, Speech Writing Secrets of President Bill Clinton. I'm just going to bullet point the main parts so you'll need to read the article to get the full context.

The power of presence - Remember that non-verbal presentation is extremely important. Your expressiveness, gestures and the way you carry yourself make a huge difference. Refer to my post, The soft-side of presentations for more information.
Customizing the message - Tailor for your audience. People like the personal touch. Speak to them.
Repetition - Think reinforcement. Reinforcement.
Using metaphors - Use simple metaphors to help explain more complex topics.
Develop empathy with the audience
A call to action - Tell them your goal. What do you want them to do?

Agile versus business agility

2006-04-05T05:54:00.000-04:00

When I hear the word agile, I think of the class of system development life cycle methodologies that are fairly people-oriented. Agile methodologies assume that change will occur and they are flexible enough to handle it. Characteristics include (you can also see my post called, Choose a methodology that suits your project):

Short iterative cycles.
Frequent, defined client feedback.
Changes (evolution) from one iteration to the next.
Modification of previous components to adapt.

As companies migrate their systems to more of a service-oriented architecture (SOA) approach, agile development methodologies are proliferating. These approaches are very useful for developing reusable components - a necessity for SOA.

What does "business agility" mean?

The ability to rapidly adapt and capitalize on opportunities or overcome problems. It does not necessarily imply that you are reactive or proactive. In truth, agility means you can adapt readily in preparation or response to stimuli. Obviously, having reusable components and an SOA framework support business agility. However, true business agility is more than just that.

I remember reading, The Regis Touch - New Marketing Strategies for Uncertain Times by Regis McKenna. In his book, Regis illustrated one of the best examples of business agility that I have come across. He recalled an experience he had when he was working as a consultant with Intel. Intel's sales teams had encountered a issue with their customers asking them about a pending competitive microprocessor product launch from Motorola, the 68000 processor. Customers were considering holding off purchases until they could assess Motorola's offering.

This message reached the ears of Intel's executives who organized a marketing response which included their product roadmap and vision. In addition, they setup seminars with clients where Intel could capitalize on the credibility of their executive staff (e.g., Gordon Moore & Andy Grove.) This marketing strategy was relayed back down to their sales staff who championed it.

Intel's actions avoided a significant competitive threat. The amazing part is that it only took 7 days for Intel to generate their positioning strategy and put it into place. That's business agility!

Thoughts on decision-making

2006-04-02T00:10:00.000-05:00

According to new research on the Discovery Channel's website, cockroaches get together to make group decisions about things that affect them as a community. Even more astonishing, cockroaches do so without being able to make sounds. Perhaps, we can learn something about the science of decision-making from them.

Common myths about decision-making

The more time I spend analyzing before making a decision, the better the decision I will make. Sometimes you can spend too much time making a decision. Your indecision could allow a competitor to seize the initiative.
In retrospect, a decision that did not work out was a bad one. Because something did not work out does not mean a bad decision was made. There are many things that are beyond your control that can affect a situation and cause an undesirable outcome. This does not imply the decision was incorrect.

What's it worth?
Here are some basic questions that you should consider to understand the importance of a potential decision.

Does it contribute towards meeting your goals or objectives?
Does it contribute towards the goals and objectives of the company or greater good?
What is the risk associated with an inappropriate choice?
How much time are the key decision-makers and you willing to provide? If no one is willing to give time, then how important do they really view it? (I'm a little draconian here, I'll admit.)
What are the associated benefits and costs of making the decision?
What happens if I do nothing?

Some decision-making techniques

To help you with your decision-making needs I have listed off a few different techniques that may be useful.

Paired comparison analysis is very useful when there are defined alternatives. The basic premise is to use a grid to directly compare one alternative versus another. The alternative that wins out against the others the most will be chosen.
Use a SWOT analysis to evaluate different solutions to a problem or opportunity. This will give you an understanding of their overall appropriateness.
Grid analysis involves comparing alternatives against a defined set of important criteria. The winning alternative will be the one that scores the best.
When you have a few different issues to address and you are trying to determine which one to attack first, Pareto Analysis, can be very useful. It involves identifying the most pressing problems.
Decision-trees are very useful to help you visualize all of the possible outcomes. You need to be able to estimate the likelihood of a path being followed as well as the value of the path (e.g., outcome.)
One can use the 6 Thinking Hats methodology to examine the different aspects of a situation before settling on a solution. This methodology was developed by Edward de Bono and can be applied to innovative thinking as well as decision-making.
Force field analysis is extremely useful to understanding the different forces that affect an issue. The great benefit from this technique is that it will illustrate all of the areas that will be impacted and may require a change management process because of a pending decision.

Some other great resources

Stay committed to your decisions, but stay flexible in your approach. (Tom Robbins)

A problem solving paradigm

2006-03-30T21:02:00.000-05:00

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

2006-03-27T18:58:00.000-05:00

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

2006-03-26T17:24:00.000-05:00

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

2006-03-23T23:43:00.000-05:00

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?!

2006-03-21T19:47:00.000-05:00

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

2006-03-19T21:46:00.000-05:00

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

2006-03-18T22:12:00.000-05:00

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

2006-03-15T00:31:00.000-05:00

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.