Tag: Project Management

Terms, Terms, Terms. Clarifying Some Business Analysis and Project Management Terms

Written by Elizabeth Larson on October 12, 2010. Posted in Articles.

In order to clarify some basic concepts of business analysis and project management, we need to distinguish between terms that seem similar but are not. Below are some foundational terms and distinctions.

1. Project Management focuses on the work and methods to create new products. The Guide to the Project Management Body of Knowledge (PMBOK^® Guide – Fourth Edition) defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”[1]

2. Process Management concentrates on the workflow and systems that recreate the products that sustain an organization.

3. Products. Throughout this article, we’ll refer to the end result of the project as the product. It can be a product, service, or any key deliverable that is produced as a result of the project. A few examples of products include a new bridge, a new methodology, landscaping, a project management office, a new car, a feasibility study, an HOV lane added to a freeway, a recommendation, a new or changed process, a new banking service, a new website, creation of a new agency, and a new marketing campaign.

4. Product Management uses processes and knowledge to manage product development, support, and marketing of the product. In this article, we cover the part of product management that occurs prior to deploying, selling, and supporting the end product. We focus on the work needed to define the requirements of the end product, to ensure that those requirements are built into the product and tested, and to ensure that the end product meets those requirements. Product managers exist in some organizations as the driving force behind new product development. They often define the high-level product requirements. In such organizations, this product manager often fills the role of project sponsor. See Table 1.1 for a summary.

Characteristic	Projects	Product Requirements	Processes
Ownership	Sponsor	Sponsor	Sponsor
Keeper or custodian	Project manager	Business analyst	Business process analyst
Planning	Project management plan	Requirements management plan	Documented processes
Execution	Performing project execution	Performing BA activities	Performing the process steps
Closeout	Project close and lessons learned	Closeout of phase(s) & lessons learned	Improved processes
Aligns with organizational vision and strategy?	Must	Must	Must

Project, Process, and Product Requirement Characteristics

Projects are initiated in a variety of different ways, such as new government regulations, competitive market forces, and requests to enhance existing products. In other words, someone in the organization requests a new or changed product.

The person who initiates the request is called the sponsor. We’ll explain the full sponsor role later, but for now let’s think of the sponsor as the person who obtains the funds for the project and makes key business decisions.

Once the request has been approved, a project manager can be assigned to manage the project. Projects result in changed processes for an individual or group of individuals large or small. For example, a new bridge results in new traffic patterns and new processes for those taking the bridge. Landscaping requires processes to maintain it; the HOV lane requires new laws and new processes for use by drivers. A new computer system results in new processes for the end-user. Therefore, stakeholders affected by projects, processes, and products all need to be identified and kept informed of the project status. Figure 1 below shows the interrelationship of projects, processes, and products.

Figure 1: Projects, Processes and Product Requirements Interaction

Life Cycles, Phases, and Methodologies

Project Life Cycle. A project life cycle takes the project from its inception to its conclusion. In other words, each project is alive. It is conceived, born, it matures, and finally ends. Products have their own life cycles. Typically, product life cycles last longer than project life cycles, because in general the product outlasts the project. However, in the example of a lengthy feasibility study whose product is a recommendation, the life cycle of the project can last longer than the end product. Project life cycles are composed of one or more project phases.

Project Phase. The project phase,as described above, usually marks a milestone, at which point a deliverable is usually produced, reviewed, and approved. The business analysis phase(s), then, produces a set of requirements (features and functions) that must be reviewed and approved.

The names of the project phases do not have to be the same for each project. One organization may have projects in different divisions or business units or agencies, all of whom can have different phase names. Nor are there a set number of phases required for each project. For example, the number of business analysis phases for a software development project can vary, depending on the approach taken to business analysis and the phase-to-phase relationship used. The business analysis effort can occur during one project phase or over the course of many project phases. For example, iterative development of software projects occurs over several project phases, as could the piloting of new business processes. For a complete discussion of lifecycles and phases, please refer to the PMBOK^® Guide – Fourth Edition, section 2.1.2.

Methodology. This prescribes how to get through the project life cycle, including the business analysis phase(s). It usually includes processes, procedures, forms, and templates for completing the project or project phase. Each project phase could, but does not have to, follow the same methodology. There are methodologies for completing business analysis, project management, product development, and testing to name a few.

Iterations, Increments, and Releases

These terms have created a great deal of confusion over the last several years. In the blog Don’t Know What I Want But I Know How to Get It, Jeff Patton uses art, movies, and pop music to explain the difference between “iterating and incrementing.”[2]

In a PowerPoint presentation, Managing Increments and Iterations with “V-W” Staging, Alistair Cockburn distinguishes iterations and increments by referring to increments as “build, deliver, learn, build, deliver, learn,” and iterations as “build, examine, learn, rebuild, ship.”[3] For another short differentiation, see Kevlin Henney’s article from December, 2007.[4]

Incremental development implies that new features and functions are added with each increment. For example, software can be developed using a plan-driven approach, with increments or new functionality added incrementally. Incremental business analysis implies that requirements are defined for an increment, and new requirements are added for each increment. Again, releasing in increments is appropriate for both plan-driven and change-driven approaches.

Iterative development implies planned rework. We expect the product requirements to evolve and change, so that change is viewed as part of the development process, not as a defect. Each iteration evaluates what has been built, and the product is rebuilt as needed. Iteration implies planned rework, because not only do we expect requirements to evolve, but there is a process to handle changes iteratively. Change-driven business analysis combines incremental and iterative requirements definition.

Product and Solution

Although the industry sometimes treats these two terms synonymously, we will use the term “product” for the end result of the project, and the term “solution” to mean the implementation of the requirements. The solution is a term used to describe a set of key deliverables that when taken together solve the business problem for which the project is undertaken.

Here are some examples.

The productof a project is a new marketing campaign. One solutionmight be to hire a consulting firm to produce the campaign. Another solutionmight be to have the advertising department develop it.
The productof a project is a new piece of software. One solutionmight be to build the software. Another solutionmight be to buy it from a vendor. Yet another solutionincludes new software, new hardware, and new processes.
The product of a project is a new order replenishment system. One solution might be the software, hardware, new and changed processes, and a recommendation on whether or not the organization is ready for the change. The requirements describe the features, functions, and capability of the new system. The deliverables (work products) from business analysis include a business requirements document, a recommendation on new hardware, a model of the future processes, and a recommendation on a new organizational structure for the affected business units. The order replenishment system alone will not solve the business problem, so the solution has to include more than just the system. This solution may involve many projects, each of which will have products.

Summary

Making distinctions in terminology is important for both planning and execution of projects, and common language can help reduce misunderstanding and miscommunication. When everyone understands the underlying concepts of business analysis and project management and uses the same terminology, they can complete the work more productively and with less conflict.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (C BAP ) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

Management Institute. A Guide to the Project Management Body of Knowledge, Fourth Edition (PMB[1] Project OK^® Guide). Newton Square, Pennsylvania: Project Management Institute, 2008. p. 435.

Patton, Jeff. “Don’t know what I want, but I know how to get it.” Agile Product Design. 21 Jan. 2008. <http://www.agileproductdesign.com/blog/dont_know_what_i_want.html>.

Cockburn, Alistair, “Managing Increments and Iterations with ‘V-W’ Staging.” <http://alistair.cockburn.us/>.

Henney, Kevin. “Iterative and Incremental Development Explained.” Search Software Quality. 3 Dec. 2007. 29 Jan. 2009 <http://searchsoftwarequality.techtarget./news/article/0,289142,sid92_%20gci1284193,00.html>.

Nomination for the Most Misused Word in IT Projects

Written by Keith Ellis on September 20, 2010. Posted in Articles.

Every industry has its own language … just like every industry has a set of marketers out there just itching to bastardize that language. It’s a situation that leads to all kinds of confusion which, in turn, leads to all kinds of sage consultants able to charge all kinds of dollars to sort the situation out and keep the great wheels of commerce churning. The technology industry is built, to some extent, on bafflegab, trends, fads, and on some outright goofy ideas turning into mainstream approaches. This is the good stuff that keeps the industry dynamic, entertaining and employing so many of us as the pedants argue about whose cloud is whitest.

It’s the more mundane misuse that’s insidious. You’ve seen it in meetings: two people in the same meeting talking about the same thing and using exactly the same words yet having exactly the opposite meaning. Business analysts should have written for Abbott and Costello – only instead of “Who’s on first”, we ask something innocent like “What’s an order” … and watch the conversation go. Let’s face it, communication is wonderfully imperfect.

Personally, I’d like to nominate the word ‘scope’ as the most misused word in IT. Every project has it, ask anyone about a project and they know it, and you can over-, under-, de-, re-, and add-just-about-any-other-adjective-in-front-of-it… scope! Scope also tends to mean something entirely different to everyone in the room: to a business person, it’s often synonymous with ‘objectives’, for the developer its modules of code, for architects its more portfolio focused. The difficultly is that the word scope means something different to every stakeholder group.

The biggie is the difference in meaning between project managers and business analysts – they are just not the same thing. For project managers, scope encompasses the project from inception to implementation and has charter through implementation tactics. For business analysts, scope means something entirely different; it’s the ‘scope of analysis’ or the breadth of functionality they need to analyze to determine the business requirements. Candidly, it is not the same thing even though analysts like to use the same word. Just because the project manager knows the scope, does not mean that the breadth of work required of analysts is particularly well understood. This error leads to all kinds of problems for the business. One of the biggest is not setting aside a discrete step in many project management approaches to actually determine this through a requirements planning activity. Kudos to PMI – they recognized this in the new PMBOK.

Language has all sorts of fun twists, most of which just need to be discussed so you get to a common understanding. It’s when the disconnect gets engineered in to the way companies work on an ongoing basis that it creates problems. So my vote is for “scope” as the most misused word in projects today.

What’s yours?

Don’t forget to leave your comments below

How Do You Project Confidence Leading Meetings When You’re Really NOT?

Written by Dana Brownlee on September 7, 2010. Posted in Articles.

The Problem

Oftentimes we’re thrust into situations where we’re expected to lead a meeting, and we may lack the confidence we think we should have. Maybe we’re not confident because we’re new to the organization, possibly we’re not as knowledgeable about the subject matter, or maybe we’re not as senior as some of the attendees….There are a whole host of reasons why we may experience feelings ranging from slight intimidation to downright terror!! Don’t fret…Here are a few simple tips to help you when you need to lead a session with confidence!

Some Suggestions

Use an ice breaker or other meeting opener that works well with groups. This allows you a few minutes to calm your nerves and establish a strong start with the group.
If possible, start the meeting with creative introductions (including a funny fact like each person’s first paid job). This shifts the focus from you to the attendees and also creates a bit of levity.
Scope out the room at least a day prior. If possible, test out all the AV equipment to be sure everything is working properly.
Gather information on the attendees prior to the session. The more information you have the less nervous you will be.
Meet with key players prior to the session. These pre-meetings can provide great insight that might impact your agenda or facilitation plan. It also offers an opportunity for you to get to know you audience. It’s always less threatening to lead a session if you know the attendees.
Make sure you have a written Purpose, Agenda, and Limit posted in the room before the meeting starts so you can easily refer to it once the meeting starts. Having these items posted and easily accessible ensures that you don’t get flustered and forget to cover them or miss key points.
Prepare! Prepare! Prepare! Review your agenda and facilitation plan with a key ally who can give you honest feedback a few days prior to the session.
There’s nothing like experience to help soothe your fears. Take a facilitation training class to build your skills.
If possible, try to have food at the session. Food improves everyone’s mood!

Don’t forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. a boutique professional development corporate training firm. Her firm operates www.professionalismmatters.com and www.meetinggenie.com, an online resource for meeting facilitation tips, training, and instructional DVDs. Her latest publications are “Are You Running a Meeting or Drowning in Chaos?” and “5 Secrets to Virtually Cut Your Meeting Time in Half!” She can be reached at [email protected].

Managing Up; Tips and Tricks for the Project-Challenged

Written by Fred on August 31, 2010. Posted in Articles.

Managing Up is Vital

If you are a busy business analyst or project manager or even if you combine both roles by necessity, you already know from experience that “managing up” is a big deal. Failure to influence your boss’s boss, sponsors, and anyone else more senior to you to pay attention to important project details and give you their buy-in and commitment can have very serious consequences. You, your team, your organization, and your customers risk lost time and money, scope creep, poor quality results, lower innovation, reduced productivity, and higher levels of stress and burnout causing delays and mistakes due to high turnover and absenteeism. The following six tips and tricks will to help the project-challenged who know that “managing up” is important and would like to be proactive in doing more of it better.

Managing Up is a Mindset: You are the Pilot
Imagine you are in the pilot seat in an airplane and you see a view of your project approximately 10,000 feet beneath you. Keep this “big picture” view in mind when you attempt to influence upwards.
You Have About 20 Seconds
All it takes if the first 20 seconds of a conversation with a boss, sponsor, or other individual more senior to you for him or her to gain or lose attention and interest. So use your time wisely by focusing on the most important things first, such as the outcome, risk, benefit, or issue. Leave the details for later.
Train Them to Say “Yes”
Ask questions that are easy for them to say “yes” to, such as: “Do you agree that we must meet our targets?” or “It is important that our internal customers have their requirements met, right?” When they say “yes” to questions about the big picture, you are actually training them to say “yes” later when you ask them to commit to more specific things. Gaining their attention and interest first is necessary if you want their commitment and action later.
Plan Your Message to Start at the End First
Start at the end first. State your recommendation or the results expected and identify related risks, options, or changes next. Remember that the other person is also a pilot and is looking at the project from afar. It is up to you to focus him/her on exactly what you need and want and once this is understood, you have done the ground work to address more specifics.
Train for the Marathon
If you were planning to run a marathon, you would probably not expect to reach the finish line without sufficient training and participation in shorter races. It is the same with managing up. You also need to train ahead of time to build stamina and experience. Prepare for the marathon experience of managing up by creating a managing up marathon training program consisting of short spurts of conversations that give you experience and help build confidence. Choose topics for these conversations that are not high-risk, such as asking for commitment to change a small part of a project or recommending a project change that has a positive impact on productivity or the bottom-line. Your goal is to prepare for bigger, more complex marathons requiring more stamina and confidence.
Practice, Practice, Practice!
Don’t restrict your training to actual projects. Find ways to practice “managing up” in your personal life as well. Create a list of people you can practice with, including: colleagues; friends; professionals outside of work. Try asking them for something, assuming they are senior to you. If you are a member of a professional association, club, or group, seek opportunities to influence others with more authority or seniority than you and then ask for their feedback.

Summary

Managing up is a skill as well as a mindset. It requires the perspective of a pilot, the ability to plan and deliver your key message efficiently, training yourself and others, and ongoing practice for success. Like anything else that is worthwhile, if you make the right choices about how to spend your time and energy to prepare properly, you have greater chances to achieve better results.

Don’t forget to leave your comments below

Dr. Gail Levitt is President of Levitt Communications Inc., a global organization in Mississauga, Ontario with affiliates in Vancouver, Ottawa, Montreal, and Boston. Gail is an accomplished author, facilitator, and coach, specializing in leadership communications, critical thinking, and problem solving. She has over eighteen years of success, leading and advising diverse teams in managing people and projects. Some of Gail’s customers include: RIM; Bell Canada; HSBC; Telus; ACETECH; Project World; ESI International; Sauder School of Business, UBC; ACETECH; Transport Canada; Canada Post; Toyota; Starwood Resorts International. Dr. Levitt is currently writing a book on team leadership for business analysts and project managers.

The BA and the PM

Written by Marcos Ferrer on August 10, 2010. Posted in Articles.

(With thanks to Lewis Carroll’s “The Walrus and the Carpenter”).

The vision shined upon the project,
Shone with all its might:
It did its very best to make
The plan seem smooth and bright–
And this was odd, since projects grow
From hidden dark of night.

The BA waited sulkily,
Because she thought vision
Had no real meat to back it up
Yet budgets were all done–
“It’s very rude of it,” she said,
“To come and spoil the fun!”

The team was set as set could be,
The keystrokes start to fly.
You could not see a coder ’cause
They busied on UIs:
No time to architect things right
Only time to fly.

The BA and the PM
Were walking close at hand;
The BA wept o’er missed requirements
Such projects were in Stand-
-ish and Gartner and Chaos
Such projects would crash land!

“If seven JADs, each with models
Analyzed half a year.
Do you suppose,” the BA said,
“That they could get it clear?”
“I doubt it,” said the PM,
“The deadline is too near”

“Oh Stakeholders, come walk with us!”
The PM did beseech.
“A pleasant walk, a pleasant talk,
Along the UI veil:
We cannot do what vision wants,
With luck you cannot tell.”

“The time has come,” the BA said,
“To talk of many things:
Of business rules and process too
Of re-en-gi-neer-ing
And why root causes were left out
And whether screens DO things.”

“But wait a bit,” Stakeholders cried,
“Before we have our chat;
For most of us are scared of change,
Don’t make us talk of that!”
“No hurry!” said the PM.
He smelled a sly way out.

“A Use Case now,” the BA said,
Is what we chiefly need:
Its what it does, not how it looks
That gives our project speed
Now if you’re ready, Stakeholders,
We can work out the true needs.”

“But not from us!” Stakeholders cried,
Turning a little blue.
“Asking us to think so hard
About the things we do!”
“The project’s fine,” the PM said.
“Don’t let BA bug you.”

“It seems a shame,” the BA said,
“To play them such a trick,
The vision could be made to work
If we just work on it!”
The PM said nothing but
“You think the screens are slick?”

“I weep for you,” the BA said:
“I deeply sympathize.”
With sobs and tears she analyzed
Important gaps of largest size,
Wrote them down, turned them in
And then kissed them goodbye.

“Oh Stakeholders,” said the PM,
“You’ve had a pleasant run!
You told us what to build on screen
We kept you happy, weren’t it fun?”
“Couldn’t care less!”, as they confessed
The system pleased no one.