Articles (578)

0

Monday, 21 November 2011 10:39

How Many Projects Are We Delivering This Year?

Written by

Every year there is a mad scramble by most companies to secure budgets internally for projects they intend to do for the following financial year. Typically, companies are flooded with requests from various departments to deliver capabilities and benefits through a variety of projects and programmes. However, companies are acutely aware that there has to be a balance between the long wish list of things to do, and the organization’s actual ability to deliver them. Usually this leads to an onerous quest to estimate the number of projects and programmes that can be delivered in a single year. In the absence of a workable corporate planning process (one that provides a prioritization framework to validate whether the right projects should be done or not) this becomes a daunting exercise for executives and their senior management teams. The purpose of this article is outline a number of techniques which on their own or collectively can assist companies to overcome this dilemma.

Establish a project filtration standard.

Given the chance, business units will add anything to the company’s list of things to do. Items that would never qualify as project work are often added. Once all the business units have finished contributing, the wish list is usually very long and lacks detail. Trawling through such a list and deciphering every item is a tedious exercise. Furthermore, to discover that a significant proportion of items do not constitute project work is extremely painful, and quite frankly a waste of the company’s time! To minimize the inclusion of non-project items and to encourage sufficient detail to reduce protracted dialogues with the business units demands a project filtration standard to be established and communicated to the relevant parties.   At its simplest level, this could entail distinguishing between development work and operational work. In practice however, a more versatile standard is required to perform the filtration. This should consist of: a business case for the intended project work, its alignment with the corporate’s strategic objectives, project size (small, medium, and large) and high-level project information (sponsorship, scope, objectives, time lines etc.). If the filtration standard is implemented correctly, it should preclude items like “photocopier installation, exchange server memory upgrade, 10 employee desks” from appearing on the list. Additionally, short sentences to describe project work such as “ERP system is required because everyone else has one, and it will take 6 months to implement” will be actively discouraged and excluded from the list, unless sufficient detail is provided.

How much money is available to spend on projects?

Another technique that can be employed to restrain the company’s wish list is to impose an overall project budget for the company. The total budget can be divided into specific budgetary envelopes which the business units use to calculate project submissions. However, the value of the total project work submitted must not exceed the overall project budget, but individual envelopes can be exceeded. In practice, this requires strict rules to regulate negotiations between the various business units; otherwise there is a danger that whole exercise can become protracted.
A variation to this approach is to set a specific monetary threshold to admit project work into the company’s to do list. Therefore, if an item meets the threshold value, it is included on the list. Nonetheless, an overall cap on project spending is imposed to inhibit too many items from entering the list. Whilst both approaches are quick and dirty, they lack the intelligence to ascertain what really constitutes project work.

Use historical data to determine organization’s capability to deliver.

The two techniques described so far, are good at restricting the company’s wish list, but are quite poor at providing an indication as to how many projects the company can actually deliver. One technique that can help in this respect is to use historical project data to determine the organization’s current ability to deliver number of projects. The accuracy of this method is greatly dependent upon the quality of the project data: if the project data is incomplete, inconsistent, or contradictory, then it may be prudent to use procurement data to calculate just how many projects started, or stopped, in a given a year. However, even this may not be enough to provide an answer with certainty. If the quality of project data is too poor to provide a reliable figure, then benchmarking could be used to determine company’s delivery capability. However, benchmarking provides the industry figure as to what a similar size organization in a specific business area should be delivering. It is not a measure of how many projects the organization in question can deliver presently. In any case, both historical data and benchmarking can assist organizations to aim for the optimum number of projects they should deliver in a given year.

Use critical resource head count to estimate the number of projects.

An expedient method for fixing the number of projects is to base it on the number of critical resources used by the company to deliver project work.  The critical resources can be project managers, analysts, architects, designers, testers, trainers etc. All organizations have a finite number of resources and in the current economic climate; the tendency is to do more with less. Hence, resource sharing is imperative to deliver projects. So it should be quite straightforward to come up with a reasonable figure, which all parties can concur with. For instance, if there are fifteen project managers then it is reasonable to assume that they would not be able to deliver more than twenty medium size projects.

Intelligent planning

One of the ways to do more with less is to group projects into programmes and then manage the delivery to produce the requisite capabilities and benefits. The advantage of this approach is that the organization as a whole can focus on a small number of programmes in a given year. However, the greatest challenge facing such an approach is the organization’s maturity to plan and effectively collaborate. Provisions are also made for unplanned projects, or programmes, which can arise due to market conditions and regulatory edicts.

Executive threshold to sponsor projects and programmes.

Lastly, one of the biggest constraining factors is how much time executives can devote to project sponsorship. Typically, executives have their schedules full with strategic, operational, management, financial and commercial responsibilities. Finding time to sponsor projects in additions to these responsibilities is a struggle for the best of executives.  Most likely, executives will not be able to commit beyond one or two major projects and programmes. Therefore, using executive attention to measure the organization’s ability to deliver is an extremely useful technique.

In conclusion, a selection of any techniques listed above can be employed to calculate the organization’s ability to deliver within a defined budget. However, this is merely a temporary solution. A more permanent solution necessitates such techniques to be integrated into the company’s corporate planning process. Only then, will the company be able to accurately determine its capability to deliver a specific number of projects and programmes each year.

Don't forget to leave your comments below.


Abid Mustafa is a seasoned professional with 18 years' experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.

Ask virtually any person inside your organization what the value of product management is and you’re likely to get a series of different answers or even quizzical looks. This is ironic, because product management is critical to company success. Although no one inside the organization wants to eliminate product management, few people can succinctly describe its value to the organization.

This begs the question, why is it so difficult for people to understand and communicate product management’s value?

The main contributor to this confusion can be traced to the lack of a body of knowledge to lay the cornerstone of the profession. Without industry-wide clarity on the profession’s core language, process groups, and knowledge areas, it’s easy to understand why product managers and extended team members struggle to describe product management’s core value proposition.

Another part of the problem is the way the product-management profession chooses to illustrate the value of the function. The traditional — and commonly accepted — view of product management typically places the product-management function at the center of a daisy wheel, the hub. Radiating from the hub is a series of circles. Each circle represents a different function — sales, marketing, and operations, to name a few. The product-management hub is connected to the spokes by a series of double-sided arrows. These arrows represent two-way communication between product management and the other company functions.

GregNov161

Source: Take Charge Product Management© by Greg Geracie. All rights reserved.

The hub and spoke model highlights two distinct but interconnected aspects of product management.  The first is product management’s primary function to ensure appropriate levels of communication between the various functional spokes, illustrated by the arrows in the diagram. The second aspect highlighted by this model is product management’s active work coordinating all of a company’s various functions in pursuit of their product objectives. This is illustrated by the neat arrangement of the surrounding circles.

The implied value proposition of this model is its emphasis on product management’s role in ensuring functional alignment and effective communication in pursuit of a company’s product goals. No one would argue that functional alignment and coordinated communication is important to the success of a product-management organization, but this model only marginally touches on product management’s true value to the organization.

The true value of product management — and what makes it so critical to company success — is the function’s unique focus on creating and sustaining value throughout the entire product life cycle. This role in the organization clearly differentiates product management from all other functions. For instance, project managers focus on successfully managing projects to completion across one or more stages of a product’s evolution throughout the life cycle. Business analysts are actively engaged in the upfront analysis of business problems, requirements gathering, and documentation. Only the product-management organization is responsible for optimizing product performance throughout the entire life cycle of a product — from conception to retirement.

Perhaps a better way to think about product management and its critical role in ensuring organizational success is to envision three pillars. These three pillars make up the entirety of the organization. The first pillar is Operations. The operational pillar encompasses the executive leadership team, shared services such as finance and human resources, and the remaining staff who spend most of their time ensuring that the organization runs smoothly. This operational group generally makes up the smallest percentage of the organization’s total head count.

The second pillar is the Value Creation Team. This pillar includes all the individuals in the organization who contribute to creating and sustaining value. This is achieved by producing new products, enhancing existing ones, or simply supporting the value that has already been created.

Depending on the size of the organization, a value creation team will be led by one or more product manager that are held accountable for achieving the company’s product objectives. Although product managers are responsible for achieving results, no product manager can do it alone. Effective product managers work closely with cross-functional product team members from across the organization. These include project managers, business analysts, engineers, quality assurance staff, research and development personnel, and customer support workers. The Value Creation Team pillar usually makes up the largest percentage of employees on a head-count basis.

The third pillar is the Revenue Capture Team. This team includes most of the marketing organization that supports the activities of the sales organization. These activities include lead generation, collateral development, and outbound marketing programs. The Revenue Capture Team also includes the entire sales organization, whose mission is to capture the revenue contractually that results from the value of the products.

When viewed from the perspective of the three pillars, product management’s value becomes clear. The product management organization acts as the focal point for value creating and sustaining activities.

Communication and alignment are important to product management’s success, but they’re secondary to product management’s real mission — creating and sustaining value throughout the entire product life cycle. This role fully differentiates product management from all the other business functions and demonstrates why product management is so critical to company success. 

Don't forget to leave your comments below.


Greg Geracie is the President of Actuation Consulting, a world-class provider of product management training courses and advisory services to some of the nation’s most well known organizations. Greg is also the author of the global best seller Take Charge Product Management© and the Editor-in-Chief of The Product Management and Marketing Body of Knowledge©.

Wednesday, 16 November 2011 09:45

PMs and Hockey Players

Written by

My son’s hockey team won a tournament recently that included a series of hard-fought, well-earned victories.  As the athletes came into the lobby from the locker room, everyone cheered, recognizing each individual contribution.  Another mom made a comment out loud that many of us hockey parents think just about every time we see them come out of the locker room: “They’re so little!”

It’s truly amazing to see 9-year-olds play hockey at the level that this team plays.  They skate on the ice as though they’re dancing on pavement.  They handle a stick with astounding skill.  They move the puck up and down the ice with agility that sometimes takes my breath away. 

Wednesday, 16 November 2011 09:33

What’s Done is Done: User Stories

Written by

Sept20thFEATUREThe definition of done is a fairly popular (and sometimes emotional) topic in the Agileverse.  It seems everyone has an opinion on the matter ranging from “It depends,” to “Let the teams decide,” to a meticulously designed set of business rules and criteria that account for every possible scenario.  However, as organizations adopt Agile practices (and specifically, Scrum), they seek to leverage guidance from those of us who have already blazed the trail.  Why then is this such a complex topic?

One aspect is that the word “done” is overused.  We must distinguish between different contexts of "done."  There is "done" at the story level, epic level, release level, product level, etc.  Each of those meanings of "done" has different criteria.   For the purposes of this article, we are only going to look at the done criteria for a user story.

Another aspect of the problem with done is perspective.  The word "done" is often used to mean "complete," as in a Scrum team saying, “We are DONE with this story." It's also used to indicate acceptance, as in a product owner saying, "This story is done." I typically teach and coach it this way: Don't say “done.”  Instead, use “complete” and “accepted” for more specific indications of status.  This gives way to defining completion criteria and acceptance criteria (Figure 1). 

thumb_dan20th1

 

Click to expand image.

Figure 1.  Done Criteria = Completion Criteria + Acceptance Criteria

The criteria for completion are summarized as follows:

  • “Code complete” – as defined by the organization/teams
  • “Unit tested” – as defined by the organization/teams
  • “Peer reviewed” – as defined by the organization/teams
  • “QA complete” – as defined by the organization/teams
  • Documented (as needed; determined by the Scrum team through tasking at the beginning of sprint)

The Scrum team determines when the completion criteria have been met with the guidance of the Scrum master.  At that point, the story is considered “complete.”

The criteria for acceptance are summarized as follows:

  • The list of expectations for a specific user story as defined by the product owner prior to the beginning of a sprint.
  • The product owner may define these alone or with the help of the Scrum team and/or Scrum master.
  • For cases where acceptance criteria are not clear, a spike user story will be used to define the problem and acceptance criteria for a user story to be completed in a future sprint.
  • The Scrum team must agree to these acceptance criteria at the sprint planning meeting.
  • Minor changes to the acceptance criteria once the sprint is underway are acceptable as long as there is formal agreement between the Scrum team, Scrum master, and product owner
  • When the Scrum team believes these acceptance criteria have been met, the user story is ready for a product owner review (demo), which occurs throughout the sprint
  • The review (Demo) of each user story should NOT be left until the very end of the sprint

The product owner determines when these acceptance criteria have been met.  At that point, the user story is considered “accepted.”

This approach provides a framework that is modular and can be adaptable around the definitions of “code complete,” etc. but clearly delineates the roles and responsibilities associated with delivering and finalizing work.  If a particular organization is striving toward 100% automation of functional tests that become part of a holistic regression test suite, then “creating automated test scripts” would be expressed in the QA complete criteria.

Further, one group might agree on what “peer reviewed” means but not the “QA complete” criteria.  Using this modular definition, each group can customize these definitions to suit their team’s specifications.

As part of this exercise of defining “done,” I have also identified in the following diagram (Figure 2) the different stages at which events occur in terms of the definition of done:

thumb_dan20th2

 

Click to expand image.

Figure 2.  Definition of Done Process Mapping

The first column defines the event or phase during which the activity in the second column takes place.  Column three shows who is responsible for the action item in column 2.  In one of the teams I am coaching, there was a highly contentious relationship between the product owner and Scrum team, and this diagram helped sort through who was responsible for what and when.  This, along with a well-defined definition of “done,” set expectations and the conflict was neutralized.

Each organization (and team) must come to a consensus on what the definition of done is for their particular projects/products at various levels (story, sprint, release, etc.)  In the next installment of this series, I will explore what the definition of done is at the sprint level.

Don't forget to leave your comments below.


Daniel James Gullo, PMP. CSP, CSM of Trinacria Consulting is a proven leader in the field of Information Technology and Information Systems who advocates and evangelizes best practices and quality for projects in all areas of business.  Specializes in delivering software development and testing projects which are on-time, under-budget, and high-value. A professional with demonstrated success in Agile and traditional project / program management, business analysis, quality assurance, and consulting services.  A highly praised and recommended consultant with an extensive history of satisfied customers and clients.  Fiscally minded with both local and global experience.  Open to travel both domestically and internationally.  Effectively manages teams and resources around the globe both on-site and remotely.

Project managers have the immense task of juggling requirements and resources that are often not under their direct control in order to produce the required project deliverables within the limited constraints to which they must adhere (scope, time, quality, etc.). Even if the perfect project plan could be designed and executed, it would not remove all of the risks that could ultimately impact a project. Plans must inevitably change for one reason or another.

Wednesday, 09 November 2011 10:34

Project Management Tips and Tools

Written by

Successful project management abides by several principles. Essentially, every project needs three components to be successful: it must come in on time, within budget, and to the degree of quality that is expected. Sounds easy enough, but every experienced project manager knows that anyone who counts their proverbial chickens before they hatch will not complete the project on time, budget, or with quality.

Successful project management has tended to rely on time-tested and proven methods of planning, managing, and charting workflow throughout the project cycle. The old saying, “When it’s not broken, why fix it?” can certainly be applied here; however, what if a new way of managing the workflow in a project cycle was more efficient, more accessible and more transparent to all members of the team?

Wednesday, 02 November 2011 09:29

Why You Should Align Your Project and Company Goals

Written by

Each year, as project managers we take courses and read articles and books on how to improve our project management skills: how to track the critical path, influence without authority, tackle bigger scope and bigger budgets, work with remote teams, flush out the ‘right’ requirements, engage the teams we’ll need for success and many other topics. Often, these are great courses and articles with great tips and advice that we use every day to deliver projects assigned to us. One area where PMs aren’t always included—or do not involve themselves in—is the project selection process, that pre-initiation stage where the project is still a concept, someone’s brainstorm or someone’s personal pet project.

Part II: The Solution and Its Value

Viewing Cyber Security as a Business Solution

As a continuation of Part I, although advancements in technology have enabled organizational strategies they came with a price to pay given the rise in cyber breaches.  Cyber security continues to be a moving target with no final technological solution insight. Considering the rate of progress in new technologies and their social prevalence, solutions are now more dependent on a person’s mindset, critical thinking abilities, and an increase in individual responsibility. These facts lead us to believe that the most effective resistance against cyber threats must now be built on shifting an individual’s mindset, adjusting human behavior and evolving legacy methodologies. Cyber security has elevated to become a required attribute for successful organizations and career professionals going forward.  Cyber safe practices require a proactive approach in addressing a new generation of cyber breach challenges associated with strategic asset delivery and survivability. The first step project managers should take is to make cyber security a priority and position cyber safe practices as part of the solution in the upfront initiation and planning processes. Project managers and delivery team professionals such as business analysts should also incorporate cyber security practices into the remaining project phases to ensure traceability of established cyber security requirements.

Wednesday, 26 October 2011 09:35

Got Projects Going Over Budget?

Written by

FEATUREOct26thYou’re not alone. Project cost overruns are common.

Statistics will tell you that over 85% of projects go over budget. But why? What are the mechanics behind project cost overruns and project schedule delays? Plenty of talented and experienced professionals engage in dialog about this very topic every day, and try to arrive at conclusions about how to stop projects from going over budget. In this article, I’d like to shed some light on the underlying workings as to the root causes of cost overruns and schedule delays. In order to tackle the problem of how to eliminate overruns, it’s important to understand the main reasons why they happen.

Obviously, there’s no one-sentence answer to these questions since every project is unique and the influences that trigger overruns can vary tremendously.

Luckily, however, there’s been quite a bit of research and experimentation around this exact problem — since it is a pervasive issue that so many businesses, large and small, struggle with. As a result, there have emerged some key factors we can point to that are the major contributors to projects going over budget and suffering schedule delays.

A lot of project managers and business owners have their own theories; and after a good deal of listening and reading, many will have you believe that it all comes down to one thing: Project Changes. Technically speaking, project changes are arguably the biggest contributor to projects going over budget and blowing schedule deadlines, but for the purposes of this discussion, let’s leave Change and Change Management out of it. I’m saying that because I don’t believe changes are truly the root cause of cost overruns. I believe that if you approach a project anticipating that things will change throughout the project — and you have good mechanisms and methodology to track and account for change — Project Changes aren’t really the root of the problem and should not result in a project cost overrun. (Click here to read about making the best of Project Change).

Let me repeat that another way:
Project Changes may alter the original budget and schedule, however, if you have appropriate tracking and change-management processes in place, they shouldn’t result in a project cost overrun. They’ll just shift the size and duration of the project.

That’s all fine in theory, of course, and I know that in reality nothing works quite that smoothly; but rarely does anything in a project work as smoothly as originally planned. The changes and addendums that get added and removed to a project should be viewed as merely extensions of the original plan. Therefore, your ability to handle change management is directly related to your ability to plan and negotiate on the fly. So, yes, if you can’t do this very well, it’s going to lead to some serious cost overrun and schedule delays. My take on it is that if you’re ok with looking at it that way, it’s truly the controls, planning and estimating pieces that are the root of the change-management dilemma.

So, leaving Change out of the equation, what then causes project cost overruns and schedule delays?
First, it’s key to understand that cost overruns and delays don’t just suddenly happen: they in fact happen all the time, every day in every phase, mostly in small incremental chunks. They happen in Planning, Execution, Close-out and Reflection phases along with every stage within those. To get to the bottom of why, let’s look at the four major triggers for cost overruns and schedule delays, which I’ll explain in more detail further below:

1. Inaccurate Estimates

2. A lack of real-time visibility and control

3. Poor methods to determine project progress

4. Insufficient historical information

These four items relate directly to the major phases of a typical project: Planning, Execution, Close-out and Reflection.

Project Planning

So, let’s talk about the first one, Accurate Estimating. This is probably the most obvious culprit since if you’re running a $10-million project that was estimated to be a $7-million project, well you’re pretty likely screwed to come in on budget and on schedule. Overly optimistic estimates and those done in a hurry are common. Project estimators that rely a little too much on gut-feel without documenting and qualifying their numbers can also cause estimating snags. I’m a believer in gut-feel, by the way — my only qualifier on that is with the communication and transparency around quantifying where those gut-feel numbers come from. I’ll get to that more when discussing the value of good historical information.

Project Execution

The second item, real-time control, is easily the most insidious of the four. It’s all about having accurate, up-to-date information about what’s going on in the project. Of course, part of this control thing is covered by the old-school methodology of being physically present on the job-site. The even bigger control factor, however, really boils down to project tracking. When you track all your labor, equipment, materials, subcontractors, suppliers, etc., you’re able to view daily reports on everything that’s happening on your project. You’re empowered with a wealth of information, which is the ultimate key to ‘control.’ You don’t have to wait until the end of the month to find out what happened weeks ago and that currency of information becomes the critical element of managing successful projects. Here’s an interesting fact: when something goes wrong on a project, the size of the impact it will have on cost and schedule is exponentially related to how fast you can apply corrective action. In other words, every day that goes by without fixing a problem that’s occurred on a project will accelerate the budget impact.
I hate to say it, but real-time control is also about keeping your suppliers and subcontractors honest. If you don’t have a good tracking and control system in place, getting over-charged and double-invoiced is going to be a huge contributor to project cost overruns.
The third item, determining Project Progress, is also a nasty contributor to cost overruns during the execution phase. If you don’t constantly take the pulse of where you’re at with your project, how can you possibly know if you’re on budget or on schedule? You may have spent 50% of your budget, but if you’re only 30% complete, you might have a pretty big problem. The earlier you can find out that you’re facing a potential cost overrun in your project, the more chance you’re going to have to correct it.

Project Close-Out

Having agreed-upon project progress milestones and sign-off is absolutely vital to being able to control costs and get paid. This is partly covered early on during the planning and negotiation phases when you’re defining what it means to be finished, but it obviously has to also be viewed as a continuous evaluation during the life of the project. Being able to seamlessly close-out a phase, level, task and the project as a whole enables you to stop spending money and squandering valuable time. You need to do regular forecasts on your project to get a financial and schedule picture of how far along the project is, and whether you’re ready to achieve closure on any piece of the project. Again, I know this all sounds great in theory; but the thing is, if you don’t do it, that’s where the insidious overruns creep gradually and dangerously into your projects.

Project Reflection

Looking back on a completed project (or even a partially completed project) to examine where things went well and where things didn’t go so well is an indispensable part of running consistently successful, profitable projects. Otherwise, you’re doomed to repeat the same mistakes over and over. A project retrospective is more than just having a big group-hug with your team and your subcontractors (although, a little love-collateral can help keep the peace and smooth any hiccups). A reflection is also about examining the numbers, and using that information to feed future projects. First, however, you need to actually have those numbers — and the metrics, and the reports — and this means you need to have executed on project tracking and earned value management during the execution phases of your project.
Insufficient historical information plagues many businesses trying to run profitable projects. Sadly, it’s often the case that very little data is collected during a project, so very little is known about what happened. All that’s typically available to many project managers is the summary totals contained in the corporate ERP. This is only marginally helpful, as it’s missing so many crucial details that help planners and estimators get better at their job. Equally tragic is when information is tracked, but it’s stored in a series of spreadsheets. As we all know, the reporting and metrics you can achieve from spreadsheets is terse, vague and time-consuming to obtain.

We’ll talk more about this in upcoming articles. I hope this has been helpful. Please leave a comment and let me know what you think!

Don't forget to leave your comments below.


Chris Ronak draws from over 20 years working with project-based businesses in management, project management and consulting positions. He is currently the CEO and founder of 4castplus, a web-based software solution that delivers full project cost management, estimating, forecasting and real-time tracking to keep complex projects on budget and on schedule.

Wednesday, 19 October 2011 11:32

The Perfect Partnership

Written by

Companies often struggle to maintain a good balance between their market activities and their product development efforts. The fact is – most new products are not ready for prime time. This circumstance leads to products that deliver less value than anticipated or fail altogether. This inability of organizations to effectively bring products to market often creates a significant drag on companies’ ability to innovate and compete in today’s rapidly changing marketplaces.

There are a significant number of reasons why it’s so challenging to effectively bring products to market.  Some are external, such as changing market conditions or shifting customer needs. However, many problems result from internal challenges such as overstretched contributors, the wrong mix of skills, poorly understood processes, and misalignment between the core team members in the value creation process.

Professions such as business analysis and project management have boundaries and roles that are well understood. Both have their bodies of knowledge, process groups, and foundational knowledge areas.  In contrast and ironically, the product management profession spans 70 years but has yet to fully codify its body of knowledge. The resulting lack of clarity on the responsibilities and boundaries of a product manager often contributes to many of the internal inefficiencies and missed opportunities we see within today’s organizations.

There is often tremendous internal confusion regarding the role, span, and scope of a product manager.  Ambiguity in the responsibilities of this role leads to dissonance and tension as the key stakeholders in the value creation process – project managers, business analysts, and lead engineers – struggle to understand what to expect from product management. Given the profession’s historical fragmentation and lack of a solidified standard, where does one look? What are the boundaries of the role and how can we work together more effectively?

Perhaps the best way to start is by defining the role of a product manager and illustrating the product management life cycle. Product managers are responsible for creating and sustaining value throughout the entire life cycle of a product. The focus on creating and sustaining value is what makes product management unique.

GG1

This product management life cycle© model is the property of The Association of International Product Marketing and Management (AIPMM)©.

The product management life cycle is composed of both stages and phases that chart the course of a product from its conception, the Conceive phase, to its ultimate withdrawal in the Retire phase. The stages and phases are concurrent activities. This framework is universal; it applies equally well to products or services.

Now that we’ve defined the role of a product manager and illustrated the life cycle, we can drill down a bit further and examine why business analysts and product managers are perfect partners.

Effective product managers spend a significant amount of time in the market gathering requirements, monitoring trends, examining competitive activity, and evangelizing their product. Product managers are also expected to distill market information into actionable requirements and channel these requirements to the team developing the product.  A product manager’s job increases in complexity as the organization grows. Product managers get stretched thinner and thinner by the ever-increasing volume of internal and external demands.

When this happens, product managers naturally turn their efforts toward either market-facing or product development activities. Although product managers are skilled at both, they typically prefer one over the other and allocate their time accordingly. Many pick market-facing activities. This bias toward one or the other, and the demands that company growth place on a product manager, ultimately causes the organization to feel the need to add a business analyst, or someone with similar skills, to the team. The new team member is tasked with helping facilitate, communicate, analyze, and recommend business solutions as well as translating high-level requirements created by the product manager into implementable requirements. This need for translation necessitates a collaborative partnership between a product manager and business analyst.

The pairing of a strong business analyst with a market-facing product manager can result in a perfect partnership. The product manager assumes responsibility for guiding the product successfully through its life cycle and interfacing with the market. In concert with the product manager, the business analyst drives the effort to turn high-level market requirements into requirements that are implementable within the constraints and capabilities of the organization. Factors such as people, processes, and technology are all key considerations for success.

This division of labor leads to improved harmony with the principles on the core team of product managers, project managers, business analysts, and lead engineers. Most importantly, it places the right people in the right roles to create value for the organization, customers, and stakeholders.

The reality is that product managers are often faced with the nearly impossible challenge of spanning the market and the multitude of development activities. And like project managers who steer complex and interdependent initiatives, product managers who want to succeed must rely heavily on influence and shared organizational objectives while interfacing with customers and coordinating the activities of a myriad of internal stakeholders. Many product managers get stretched to the breaking point trying to be jacks of all trades and end up struggling against unrealistic expectations.

By pairing business analysts with product managers at key points throughout the life cycle of a product’s development, organizations can optimize bandwidth, expertise, and interest-related challenges that allow both roles to do what they do best – create value. 

Don't forget to leave your comments below.


Greg Geracie is the President of Actuation Consulting, a world-class provider of product management training courses and advisory services to some of the nation’s most well known organizations. Greg is also the author of the global best seller Take Charge Product Management© and the Editor-in-Chief of The Product Management and Marketing Body of Knowledge©.

David Heidt is a Strategic Advisor, Senior Project Manager, and Business Analyst with Enterprise Agility, a worldwide leader in strategy alignment, project portfolio management and business analysis. David is President of the Chicagoland Chapter of the International Institute of Business Analysis and a contributor to The Product Management and Marketing Body of Knowledge