Tips for end-user acceptance

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

1. 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.
2. 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.
   
3. 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.
   
4. 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.
   
5. 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.
   
6. 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.
   
7. 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

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

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

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:

1. Ability to perform a task.
2. 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.

1. High ability to perform the job but low motivation to do it. Convince the employee to persevere and outline the task's importance.
   
2. 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.
   
3. 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.
   
4. 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

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:

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

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

Knowing when it's good enough

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:

1. Likelihood of the risk materializing. What's the probability of the risk becoming a problem?
2. 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

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:

1. Determine where he / she is (e.g., location) at all times.
   
2. Receive driving directions to a user specified address.
3. 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

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:

1. The requirements were not design-independent. It was pretty much determined to rework the existing reports and make them more efficient.
2. 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?

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:

1. Increase the market for its products (especially if it did not have a web presence.)
   
2. 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

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

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.

1. Your material is perceived to be unsuitable. It may be too detailed or contain too few details.
2. 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."
3. 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

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

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

1. The increase in outsourcing patterns.
2. 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

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:

• Correctness
• Completeness
• Clarity
  
• Consistency
• Testability
• Traceability
• Modularity
• Feasibility
• Design Independence

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

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

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

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

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

1. Friendliness - Make people feel welcome and comfortable.
   
2. Relevance - Validate commonalities between yourself and others.
3. Empathy - Understand feelings are facts. Be a good listener. Don't judge or try to fix the problems.
   
4. 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

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!

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

1. 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.
   
2. 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."
   
3. Some things are more important than others. Weight your criteria.
4. 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.
   
5. Establish high-med-low groups of projects.
   
6. 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

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

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

Project prioritization goals

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

1. 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.
   
2. Money, time and people are scarce resources. Proper management and effective use of these resources can only benefit a company.
   
3. 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.
   
4. 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

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?

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:

1. Understand how important a project is to you. How well does it align with your objectives?
   
2. Prioritize your projects early to allow for lead time for effective decision-making.
   
3. 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

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

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

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

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

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

1. 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.
2. Do they want more? A great sign!
   
3. 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.
4. 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

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

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

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

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

1. Assemble the material as per my plan.
2. Follow presentation best practices.
   
3. 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?

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

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.

1. 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.
   
2. 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.
3. 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.
4. 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.
5. 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

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?

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

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:

1. State the key decision.
2. Define the key selection criteria (e.g., "must haves" and "nice to haves.")
3. Rank the, "must haves." To quote George Orwell's Animal Farm, 'All animals are equal, but some animals are more equal than others.'
4. List the choices.
5. Eliminate choices that do not satisfy the, "must have," criteria.
6. Analyze the remaining choices against the, "nice to have," criteria.
7. Outline the pros and cons of each choice.
8. 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)"

1. State the purpose.
2. Outline the audience's needs.
3. What are the features of your idea (product)?
4. What are the benefits that your audience can reap?
5. What's the problem with the status quo? Why don't we want to do nothing?
6. Reconfirm the benefits.
7. Show how to achieve the benefits. What needs to be done to get there?
8. 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

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

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

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:

1. Leverage existing systems.
2. Extend existing systems.
3. Buy a vendor product.
4. 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.