Product Management vs Project Management

In this new section on PM Advisor, John Williams takes a look at the differences between project and product management, centred around the distinct processes which each discipline needs to follow.

Product and Project Process

Three questions

  1. What do you think?
  2. Is this a useful differentiation?
  3. Do you agree that the discipline distinction is essential?

As always we welcome your input – please comment below.

Project Management News Digest wk50 2013

News Digest5 Insightful Project Management Lessons from Sci-Fi


Carol Pinchefsky suggests that there’s project management advice aplenty if you know where to look, and sees lessons in the following movies/shows:

  • Star Trek: The Next Generation “Remember Me.”
  • Robocop
  • Buffy the Vampire Slayer: “Doublemeat Palace”
  • Batman Begins, and
  • Ghostbusters

How to Ensure your Strategic Initiative Succeeds


John Williams explains why strategic initiatives are projects and how to make sure they succeed.

Study Highlights the Benefits of Project Management Training

Project Accelerator

A study by training company Parallel found by surveying previous PM training delegates that:

  • 89% agreed that the training benefitted their company
  • 64% agreed that PM training helped improve their current work projects, and
  • 71% of those attending APM training agreed that it helped develop their management skills

Project Management In A Post-Mad Men World


Paul Pentzer observes 5 qualities that Advertising Agency PMs should possess:

  1. Relentless focus on solving problems
  2. Ability to simplify complex situations
  3. Good facilitators
  4. Excellent in basic PM skills
  5. Ability to model a ‘servant relationship’

Why Are So Many IT Projects Failing

Sharon Florentine reports on a trend that as more companies adopt Agile, their project managers are expected to take on more responsibilities, namely development lead.

6 Project Management Modes

Shift Happens

Mike Clayton explores the 6 main modes that a PM needs to shift through as the project proceeds:

  1. Leading Mode
  2. Supporter Mode
  3. Fix-it Mode
  4. Exploration Mode
  5. Crisis Mode
  6. Process Mode

13 Steps to Becoming a Better Product Manager


Michael Bordash considers 13 attributes of product managers, not least that Product Management is not Project Management.  Really.

A Practical Approach To Project Portfolio Management

Information Week

Part 1

Part 2

Part 3

Frank J. DeLuca looks at how to set up a good, fast, and inexpensive program that will make the best use of pricey IT resources, without costly specialised software.

5 Steps to Project Management Nirvana


Alison Green suggests that if your projects aren’t doing what they should, to try following these five steps.

  1. Get clear on the desired outcome before work begins.
  2. Establish clear roles
  3. Conduct “pre-mortems.”
  4. Build in check-ins along the way, and
  5. Debrief when the work is over.

Arras People Project Management Census 2014

How To Manage a Camel

It’s that time of year again when Arras People ask for your help to take a snapshot of our domain. It’s the ninth Project Management Census and this year they’ve really focused on the project management career.

Eylean Project Management Software Provider Launches Personal Version


Eylean, provider of agile project management software for Scrum and Kanban, has introduced a personal edition of its agile task board, which will be available to customers free of charge for personal use.

5 Ways to Build Strong Project Teams


Dave Wakeman, PMP shares his thoughts on how to build project teams:

  1. Be an active communicator
  2. Trust your team
  3. Understand your team members’ individual motivations
  4. Don’t embarrass your team
  5. Be flexible

Defining Project Requirements

It is unsurprisingly difficult to meet with customer or user expectations without a clear definition of requirements agreed at the beginning of a project. Unfortunately, too many customers are unable or unwilling to commit to requirements. Similarly, too many project managers fail to put sufficient focus on finalising their agreement swiftly enough. The requirements form the basis of a detailed project management plan. Sadly too many projects fail as a result of the resulting ambiguity.

Very often, the main cause for failing to define requirements adequately is insufficient understanding of, or confidence in, the techniques and tools needed to appropriately capture the essential project requirements.

A practical, nine-step process for defining requirements for your project or product is suggested in the book “Customer-Centered Products” by Ivy Hooks and Kristin Farry:

  1. Scope the project or product by defining needs, goals and objectives, outcomes, mission or business case, high-level operational concepts, customer requirements, constraints, assumptions, schedules, budgets, roles and responsibilities.
  2. Develop operational concepts – scenarios for how your project or product might be used by the end user. Expand the concepts to cover all phases of the product or project life cycle.
  3. Identify interfaces between your project or product and the rest of the world, clarifying boundaries, inputs, and outputs.
  4. Write requirements to guide product design toward what your customers need and want.
  5. Capture rationale (the reasons for the requirement’s existence) behind each requirement and expose potentially dangerous assumptions and incorrect facts.
  6. Level requirements according to system and system sub-divisions, ensuring that all requirements are written at the right level and can be traced back to their origins.
  7. Assess verification of each requirement, identifying the verification technique and facilities and equipment required.
  8. Format requirements and supporting documentation to ensure that you have included each of the appropriate types of requirements and that your development team members can find all of the requirements they must meet.
  9. Baseline requirements after validating that they are correct, complete, consistent, meet the project scope, and do not add unnecessary functionality or features not covered by the original scope.

Gathering RequirementsGATHERING
There are several techniques for initially gathering (elicitation) of the requirements. The following Top10 from TechRepublic provides for a thorough capture.

#1: One-on-one interviews
The most common technique for gathering requirements is to sit down with the clients and ask them what they need. The discussion should be planned out ahead of time based on the type of requirements you’re looking for. There are many good ways to plan the interview, but generally you want to ask open-ended questions to get the interviewee to start talking and then ask probing questions to uncover requirements.

#2: Group interviews
Group interviews are similar to the one-on-one interview, except that more than one person is being interviewed — usually two to four. These interviews work well when everyone is at the same level or has the same role. Group interviews require more preparation and more formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused.

#3: Facilitated sessions
In a facilitated session, you bring a larger group (five or more) together for a common purpose. In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately.

#4: Joint application development (JAD)
JAD sessions are similar to general facilitated sessions. However, the group typically stays in the session until the session objectives are completed. For a requirements JAD session, the participants stay in session until a complete set of requirements is documented and agreed to.

#5: Questionnaires
Questionnaires are much more informal, and they are good tools to gather requirements from stakeholders in remote locations or those who will have only minor input into the overall requirements. Questionnaires can also be used when you have to gather input from dozens, hundreds, or thousands of people.

#6: Prototyping
Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary requirements that you use to build an initial version of the solution — a prototype. You show this to the client, who then gives you additional requirements. You change the application and cycle around with the client again. This repetitive process continues until the product meets the critical mass of business needs or for an agreed number of iterations.

#7: Use cases
Use cases are basically stories that describe how discrete processes work. The stories include people (actors) and describe how the solution works from a user perspective. Use cases may be easier for the users to articulate, although the use cases may need to be distilled later into the more specific detailed requirements.

#8: Following people around
This technique is especially helpful when gathering information on current processes. You may find, for instance, that some people have their work routine down to such a habit that they have a hard time explaining what they do or why. You may need to watch them perform their job before you can understand the entire picture. In some cases, you might also want to participate in the actual work process to get a hands-on feel for how the business function works today.

#9: Request for proposals (RFPs)
If you are a vendor, you may receive requirements through an RFP. This list of requirements is there for you to compare against your own capabilities to determine how close a match you are to the client’s needs.

#10: Brainstorming
On some projects, the requirements are not “uncovered” as much as they are “discovered.” In other words, the solution is brand new and needs to be created as a set of ideas that people can agree to. In this type of project, simple brainstorming may be the starting point. The appropriate subject matter experts get into a room and start creatively brainstorming what the solution might look like. After all the ideas are generated, the participants prioritize the ones they think are the best for this solution. The resulting consensus of best ideas is used for the initial requirements.

There are numerous templates freely available.  We touch on project tools more here.

Often there is a temptation to use specific software for capturing requirements, and there are numerous commercial offerings to meet that ’need’, however it is worth bearing in mind that basic office tools are often just as effective.

Aha! New Roadmapping Tool for Software Products

500x195Aha! by Aha! Labs has recently come to our attention with their interesting new cloud based product management tool.

Features include: collaboration with user management, product description, change tracking, market assessment, strategic planning,  release planning, tracking & communication management, feature organisation, file sharing, messaging, roadmapping, integration with Jira, GitHub and Webhooks, and more.

There is an interesting review here at PCWorld by Tony Bradley, or you can of course check out Aha!’s website – the link is at the top of this post.  We wouldn’t be surprised to see this tool joining the specialist tools category here on PM Advisor soon.