Skip to main content

Author: Steven Starke

The 7 Minute Project Manager – Collaborative Design

The 7 Minute Project Manager evolved during the creation of the widely popular Official 7 Minute Workout mobile app. More general context and background can be gained from my initial article on this topic. My intent in writing this follow up article was to delve further into my experiences as the 7 Minute Project Manager by focusing the lens on the project itself; specifically, discussing what happened in the beginning. The early stages of the project can be best defined by what I would call collaborative design.

The project kicked off with a very small core team consisting of the Strategic Product Manager, the Creative Design Lead, the Project Manager (also filling the role as the product owner), and the Software Architect. We focused on general concepts and primary goals of the app. The Creative Design Lead immediately began creating rough sketches of what the user interface would look like. These rough sketches would be iterated over time eventually becoming the product wireframes – our bible for development. As more creative type resources became involved in the project, the project quickly became about creating a product that was “beautiful” – not a word typically spoken on most projects.

Design occurred at a very rapid pace. As initial feedback was gathered on one concept, that feedback was quickly turned into input for the next feature concept; keeping the consistency and the holistic flow of the app intact. To be clear, we were all about design and using design to drive requirements instead of the other way around – where requirements come first.

At this stage of the project, it was all about creating a product that was beautiful. But how do you create a project plan for “beautiful”? And is there a fear/risk that by using design to drive requirements that we would actually miss detailed requirements in the process? Yes, absolutely there is always that risk. But with schedule being the ultimate driver of the project and scope – defined as something beautiful – a close second in priority, there is nothing else you can do but to manage risk along the way.

As we moved further in design, I found myself needing to adapt quickly by wearing multiple hats. I would need to move rapidly from one task to the next, as I moved from one role to the next. Ironically, much like the design of the exercise circuit, this role switching was like moving from one exercise to the next, with very little rest in between. The only time I really had to evaluate project performance was at the end of a major milestone, again very similar to the My Performance section of the app where you evaluate your performance only after the exercise routine is complete.

Deliverables for this stage of the project were wireframes, concept designs, and creative mockups. Not your traditional requirements document filled with functional and non-functional requirements. To capture the requirements along the way, we annotated each of the deliverables above to ensure that our requirements were consistent with the overall design and to challenge ourselves when there was a conflict or contradiction. As the project manager for this project, I found myself managing to an ideal product end state, not a compartmentalized waterfall approach to deliverables.

We started off the project choosing Agile (specifically SCRUM) as our preferred methodology – being that speed to market was a key driver of the project. We all talked the Agile language, but there were definitely barriers to understanding exactly how we were going to use a collaborative design process to build a product from scratch, and magically break all that work down into two week sprints. To try to make some sense out of all of this and put a plan together, I had to work from the top down and the bottom up to build the schedule. Both approaches had to be done by working backwards from our launch date and then layering both schedules on top of each other to find the true dependencies, risks, and critical path for the entire project.

In this early stage, I needed to find that first schedule acceleration point to try and reduce overall schedule risk. We all quickly realized that we needed enough of the design complete so that product development could start as soon as possible. We knew that we could design enough quickly and continue to iterate over time. But we also knew that code development would be the longest leg of the project. It soon became clear to us that all paths led through the data model. If we could design enough of the product to understand what the data model needed to look like, then we could get started on code development and actually building the product sooner.

Now the trick was to determine how much of “beautiful” drives the project. Was functionality considered beautiful, or did it have to be fully polished? How much polish is truly necessary? Would our beautiful design work on both iOS and Android platforms? These questions would drive continued iterative design sessions. But we had to be careful not to allow ourselves to design to perfection. By using the project schedule, we determined when development would need to start and roughly how many sprints would be required to get us to our finish line end date. We used milestones like that to ensure our design sessions for functionality were one step ahead of when our planned sprint was for coding. Again, we needed just enough design to get started.

We knew we couldn’t be traditional Agile by doing two-week sprints with the end of each sprint being put into production. We had to have enough product features to call our product a minimum viable product (MVP) that would be well received by the market. In the world of mobile apps, product reviews and star ratings determine your success. If we didn’t put enough product features out, we would surely hear about it immediately from the market, which could spell the end of our product.

To ensure our proposed feature sets were in line with the markets expectations, we furthered our collaborative process by using past students/graduates and additional instructors from the Human Performance Institute, the birthplace for the 7 minute workout, to evaluate each creative design concept. We used pdf’s and some pretty amazing KeyNote presentations that essentially showed the navigation paths through the app. The navigation had to be quick, intuitive, and provide an experience that users like this were familiar with. In addition, we hired an outside company to recruit beta testers for us to make sure the general market perspective was understood as well. We went back and forth with review sessions before finding that right balance between what worked for a fitness instructor and what inspired the general user to want to workout and change their behavior. All in all, this feedback process was rapid, iterative, and rich with near-real time results, giving us the confidence we needed to ensure we were on the right path.

Communication tools quickly became essential in keeping the project on schedule. I needed something quick, lightweight, and virtually collaborative. Immediate feedback was required. We didn’t have the luxury of waiting for a formal deliverable review meeting to occur. Any delay in receiving feedback would immediately translate into project schedule delays. Therefore, it was required to become proficient in Cisco’s Webex collaboration tool, JoinMe, GotoMeeting, and Skype.

In addition, for document reviews in MS Word, providing comments in the document, but also embedding audio comments helped and was encouraged. Being able to hear the Strategic Product Manager explain their feedback provided more contexts and a clearer understanding of what they were trying to communicate. For wireframe and creative design reviews, we used pdf’s, embedding comments in the pdf’s and then recording ourselves using the Mac’s web camera (iSight), and then using Quicktime X to record our desktop as feedback was given. This technique, allowed a more comprehensive review of the document, where each team member could see and hear the reviewers feedback. We could literally watch the reviewer make edits as they commented on the material.

The above tools worked great for product deliverables, but when it came to actually building the mobile product, we immediately felt constrained by our inability to share, considering how many UDID’s we needed to share across the team. We quickly discovered a solution on the market called Reflector, an application by Air Squirrels, which worked excellent for show and tell of the mobile app in it’s early development state. The ability to take our mobile device and, through Airplay, reflect the device on our Mac or PC, allowed us to demo the mobile application to anyone we needed to.

As we moved pieces of design into development, we could all begin to see our “beautiful” product take shape. However, as our product became more tangible, the need to revisit design became a hard temptation to resist. It was quickly becoming clearer that, because of the intense speed of the project, we never truly defined in enough detail upfront what was required for our MVP. By not clearly having enough detail of what constituted our MVP, our continued beautiful design process would begin to wreak havoc on the schedule. Our desires to continually refine design were now bleeding too far into the schedule and downstream activities were quickly becoming compressed.

At a moment’s notice, my project schedule would completely blow up, just due to the rapid nature of the project and the impact to missed milestones. The only thing we could do when this happened was quickly perform risk mitigations. We needed to quantify the problem before we could determine the best solution. Most of the time that meant backlog grooming and scope reduction to downstream functionality. However, at some point, cutting too many features reduces your overall product value. Without a clearly defined MVP how would we know when we cut too much? I knew that to get our project back on track, I had to change the project from being one about beautiful design, to one of quantifying value. But how with such an aggressive timeline? This topic starts to get us into the next stage of the project, which is best saved for another article…

However, in the meantime, if there are specific questions or categorical topics you are interested in from this experience, please let me know and I will try to answer the best I can.

Don’t forget to leave your comments below.

The 7 Minute Project Manager

High intensity, with rapid iterations, and very little rest. Does that sound like your last project?

Well, for me, that was the product description of my last project. The idea was to develop a mobile app product, designed to increase your stamina, lose weight, and ultimately change your life. I just had no idea that, through the creation of the Official 7 Minute Workout mobile app, that all those things would actually happen to me. Yes, it was through this high intensity project, that my project management life changed, and where the 7 Minute Project Manager was born.

The 7 minute workout phenomena was started back in May of 2013 when Chris Jordan wrote the white paper describing a high intensity, interval circuit training workout, combining both aerobic and resistance exercises that could be done without any equipment except a wall, a chair, and your body weight. The workout quickly advanced through exercises utilizing one muscle group while allowing another to rest, in quick, powerful succession, with minimal rest between exercises. The original white paper described a workout of 3 circuits with 12 exercises totaling 21 minutes. However, when the NY Times picked up the white paper, they dubbed the routine “The 7 Minute Workout” and hence the craze began. Within 48 hours of the NY Times article over 50 apps were released on the iTunes Store claiming to be the real 7 minute workout. However, the “official one”, was still being talked about. We were essentially starting from a blank piece of paper. So what was my mission in all of this? My job was simple…come in, and do whatever it takes, to complete the Official 7 Minute Workout app, in time, on budget, and with enough features to displace all other competitors.

The problem:

Well, I was a contractor/consultant, coming in new to the organization and the Strategic Product Manager, I was partnered up with, I believe started three weeks prior to me getting there. And…well, we were told to find a vendor(s) who could help us build this. All we really had to work with was the original white paper, Mr. Jordan himself, and our abilities as product and project managers to deliver a killer product.

The challenge:

Complete this project within four months – an immovable deadline. If we didn’t get it out by early January, then we missed the New Year’s resolution crowd, and we failed. Plain and simple.

Hence, the 7 Minute Project Manager was born. The characteristics of this creature where based on the ability to adapt quickly, moving rapidly from one task to the next. Schedules and plans were constantly iterated and evaluated for acceleration points. Oddly similar to the 7 minute workout, the project characteristics were high intensity, iterative design and development, with very little time (rest duration) for decisions to be made. This could not be a project done by consensus. Decision making had to be swift and risk mitigation even swifter. There was no time to compartmentalize people’s roles or complain that something wasn’t your job. If there was a task that needed to get done, you did it – no matter what. Was the role I played part project manager, program manager, product owner, and QA manager? The answer is YES. All ego’s where checked at the door. This project was about teamwork and driving to meet our success criteria!

The need to quickly adapt was like nothing I’ve seen before. At a moment’s notice, my project schedule would completely blow up, just due to the rapid nature of the project and the impact to missed milestones. When this happened, we quickly performed risk mitigations and enacted the infamous plan B. But sometimes plan B wasn’t enough. There were several times where we had to go all the way down to plans C and D. Did we use Agile, SCRUM, RUP, or Waterfall SDLC’s? Well, the answer is YES. We had to use and be skilled in all methodologies for this project to work. Did we use internal or external resources? Again, the answer is YES. We used what we needed, stealing bandwidth from resources when we had to. Did we have to go through Security, Compliance, Legal, and Trademark reviews? You bet we did! Again, all of this happening over a four month time period, where stakeholder and senior management engagement increased rapidly as word spread about the project.

Our infrastructure starting the project was not set up to be virtual. Yet, at times, it seemed our entire team was virtual and distributed. We had to think quick and creatively using technology where we could to increase our communication and effectiveness. Tools like, TestFlight, DropBox, Google Docs, and Reflector were quickly discovered and tried.

In the end, some may say that this project was doomed from the start. The expectations were just not real and borderline insane. However, we did it. We completed the project on time and under budget! Not only that, but within the first week of launch, we were featured by Apple in the App Store and had over 100,000 downloads with an average star rating of 4.5. We were the top free 7 minute workout app on the App Store – and all with no app crashes and only a handful of support calls. We hit it on scope, schedule, cost, and quality goals. However, we blew away our success expectations!

My intent in writing this article is to set the stage for a series of three articles that cover more depth and details regarding the project. The first article would describe the innovation/design experience. Next, the series would move forward into development and the number of challenges, approaches, and iterations we went through. Finally, the article series would rap up with a discussion regarding the launch and marketing approach taken to deliver a successful product in the market place.

This project experience comes rich with lessons learned – both good and bad – and I feel that others should be able to benefit from it. Innovation, Product Management, Project Management, and project execution all coming together to create something special.

Don’t forget to leave your comments below.

Survey Data Coincides with Towering Project Results

Over the past couple of years, there have been several running global surveys based on determining the ideal factors that affect product team performance. The results from these surveys seem to indicate that,

In addition, preliminary results from the some of the soon to be released 2013 Product Team Survey’s are indicating that:

  • Teams are focusing too much on internal development and not enough on product launch and commercialization activities.
  • Over 38% are indicating that their team effectiveness is hampered by poorly defined roles and lack of clear handoffs between team members.

In thinking about this data, it made me reflect a bit and ask the questions “what does a well performing team look like? What types of results are possible with this high performing team?” By asking these questions, I was trying to get a bit more tactical at figuring out how I could use the data to influence the teams I currently work with, in order to achieve better results. So, I did a bit of research and came across a case study that I thought exemplified many of the aspects / results of the survey. Before I tell you the product this team created, let me tell you a bit about the characteristics of the project and the team.

  • The cross-functional team was quite large with a number of different stakeholders. The team therefore, put together a set of common, non-negotiable objectives to drive the project.
  • The initial vision of the product was clear, but the team knew that flexibility in planning and execution would be required. Market and economic viability would require continual adjustment and readjustment to plans and trends difficult to anticipate.
  • Mixed use planning and programming was utilized. In this case, we are talking about creating different programs on top of one another for different uses and different demands. Each of the different programs would be components of the overall end product.
  • The team planned to deliver in phases / stages, in advance of completing the entire product.
  • This phasing was a requirement and non-negotiable to the overall success criteria of the project. Each of the 5 stages / phases was designed so that each phase operated like a complete, self-sustaining, fully code-compliant revenue generating piece, within the greater framework of the overall product. This allowed the product to start generating money almost two full years prior to its final completion
  • The project planning didn’t follow a pre-canned methodology. But rather took the approach of tailoring the project based on the needs of each organization involved and the common objectives and success criteria driving the project.
  • The team utilized peer reviews and structural testing to reaffirm the integrity of the overall product.
  • The design utilized cost savings techniques, as well as, integrating design with engineering expertise.
  • Technology components were chosen carefully based on the requirements of the overall project. This enabled a design that was both cost effective and truly innovative. The team didn’t follow the rules. They went against the grain and did what made sense based on sound engineering practices and data. Build it once and do it right the first time.
  • Size of the project combined with immovable deadlines for revenue generation required a fast-track construction schedule.
  • Took 4 yrs from start to finish.
  • The stakeholders of this large-scale initiative gave credit to the team’s expertise in advanced planning, project management, and scheduling.

So, clearly the case study describing this great project feat seemed to be consistent with the results and analysis of the survey. So what was this amazing product? Perhaps the first iPhone or PC? Well, not even close.

The case study was based on Trump International Hotel and Tower. The tallest residential and largest concrete, building in the United States. It is also the tallest building project in North American since the completion of the Sears Tower in 1974, and one of the largest buildings to be partially open to the public while under construction.

Initially envisioned a 150-story structure that would eclipse the height of the Sears Tower, but revised after the terrorist attacks of September 11, 2001, when developers began to re-evaluate the perceived benefits, public perception, and marketability of super tall buildings. The final product was 92-story tower that would combine luxury condominiums with a world-class hotel.
Starke June19 IMO01
The team delivering Trump Tower was truly a high performing project team. With survey results like the ones mentioned above, we can now quantify what high performing means and, furthermore, predict the types of results when utilizing each of these factors of success. I look forward to the next Whitepaper and future survey results in the industry to help us practitioners change the game!

More information about this case study can be found here Case Study: Trump Tower. For more information about hybrid approaches to product development please check out my recent blog post on

Don’t forget to leave your comments below.

The Study of Product Team Performance, 2012
Market Snapshot Report on Agile Realities, Voke Study, 2012.

Let’s End the Debate Over Scrum Master versus Project Manager

FEATUREOct3rdOver the past several years, there has been much debate and confusion over the role of a project manager as the majority of organizations undergo Agile transformations. In fact, industry data suggests that approximately 53% of organizations are blending Agile methods with Waterfall.[1] 

The result of this seismic change has been that project managers have left organizations; PMO’s have been dissolved, – all because of the introduction of Agile development methodologies. And project managers are not alone. The introduction of Agile has also significantly impacted the product manager role as well; as organizations concurrently struggle to make sense of the product owner role.

I can’t tell you how many articles I’ve read and LinkedIn postings I’ve seen on these subjects. The best material recognizes that a project manager is NOT a Scrum Master and vice versa. And although the description of the Scrum Master role is usually pretty clear in these discussions, nobody has done a really good job of explaining how the two roles (Scrum Master and Project Manager) co-exist or how this role confusion started in the first place.

To be honest, I really never understood the debate. I started executing projects back in 2001 using XP (Extreme Programming) and I never had any issues with team members regarding role confusion during project execution. Agile wasn’t evil – Agile worked. Well, fast forward to 2012 and the debate continues to rage on. I finally got sick of watching the continuous debate and decided to take action. I took the classes, passed the test, and became a Certified Scrum Master. And after all that money and time spent, I can honestly say with certainty, I’m not a scrum master – I AM a project manager! 

Fundamentally, I think the root cause of the debate is not based on scrum master versus project manager responsibilities but based on our fundamental definition of a project. In the Agile world of minimum marketable features (MMF’s), product backlogs, and continuous integration, the lines of the traditional project have now been blurred. I find that the Scrum team has no issues with their responsibilities back to the product owner and scrum master, but for some reason, the entire project team doesn’t feel accountable to the project manager.

My goal in writing this article is to end the confusion and the debate once and for all. To do that, I need to remind you of what a project manager is and how the two roles should co-exist. Let me get some quick definitions on the table to help structure our conversation:

The Scrum Master – The Scrum Master focuses on the development process and mentors the Scrum team. The key responsibilities of the scrum master are:

  • Maintains and removes impediments
  • Manages the Scrum process, making the process work
  • Plans the release
  • Plans the Sprints
  • Shields the team from external interfaces
  • Facilitates Scrum meetings as requested
  • Ensures crystal clear communication among everyone involved in the project

A Scrum Master is usually the team leader. A Scrum Master should ideally have a good balance of the following skills:

  • Technical expertise
  • Understands the Product Owner’s Intent
  • A good team player and mentor
  • Understands the teams capabilities
  • A good motivator
  • Problem solver

Now let’s take a closer look at the program and project management roles and responsibilities by defining a project and a program…

Project: A temporary endeavor undertaken to create a unique product, service, or result. At most organizations, the boundaries of our “temporary endeavors” are defined through our business cases.

Program: A series of related projects designed to achieve a specific outcome(s).

To state it concisely, the role of the project manager is to manage all (Ideation to post-Launch Support) aspects of the project to achieve the expected outcomes identified within the established business case (investment) – not just the Scrum Team. The size, scope, and complexity of the business case will determine the size of the project. Achieving outcomes called out in the investment may take a series of related projects – called a program. At which point, the program manager is now accountable for managing all aspects of the program, with project managers and other accountable resources managing their smaller project portions.

Right now, there are three, possibly four basic categories of “temporary”:

    1. Product line execution – Temporary relative to a 1 year planning cycle. Basically covering minor incremental enhancements to an already existing product line.
    2. Big custom projects / new product development
    3. Within the product line – Specific temporary initiative/projects. For example, a SQL server upgrade.
    4. Cross organization initiatives – Examples that come to mind are rebranding, ICD-10 (healthcare), data center migrations, etc.

These projects / temporary endeavors at most organizations typically look like this:


And it looks like this…

And it looks like this…


If this is a project, then the project manager needs to be the one accountable person responsible for managing all of this work (or for understanding and managing HOW we’re going to get the answers to the questions above in each circle) – They are not responsible for answering the questions!

To put it simply – the project manager is responsible for managing all the boxes together to achieve the desired outcome. They may or may not be responsible for managing the individual boxes. Individual box responsibility is typically done by the subject matter experts.

As you can see, Agile development and the Scrum team are only one box!

Specifically, the project manager is responsible for:

  • Understanding the intended outcomes of the project and ensuring the outcomes are realistic and measurable. They need to understand the outcomes expected from the business case!
  • Collaborating with the team to define the scope of work (e.g. under each colored box above, what’s in it, what is the expected outcome), who is responsible for delivering it, and when will it be delivered. Specifically:
    • Deliverables required to complete all the project work
    • Cross-functional resource assignments
    • Estimates to complete the work and dependencies between work items
  • Understanding the point person from each functional team(s) associated to the work (each colored box) and how they have been allocated for managing their work. If allocation bandwidth issues exist, this person would be responsible for facilitation and ultimate resolution of the resourcing issue.
  • The job of the project manager is to remove ambiguity in roles and responsibilities by clearly mapping out activities against expected outcomes relative to time. Identifying the interdependencies between deliverables and functional teams up front will better determine what teams should be more integrated and when, relative to the overall product development process. 

Important note: if the scope of work is large enough, another project manager/person may be assigned to specific items (smaller box). The relationship would be a dotted line from this other person to the project manager.

Said another way, if each one of the smaller boxes above is large enough in scope to be considered its own project, then the program would consist of several related smaller projects rolled up underneath the program.

    • E.g. Hardware or software procurement, installation, and configuration – Application Operation Project Manager
    • E.g. Agile product development – Product owner/scrum master
  • Understanding the process and tools required to manage the scope of work relative to the outcomes identified in the business case. Understanding the metrics and the process for achieving those metrics/goals.
    • If an identified metric is that the project be completed within a certain capital budget, then the project manager is responsible for understanding the tools and processes required to forecast and track the work. They are NOT responsible for creating or establishing those processes – unless of course that creation has been identified as another project!
  • Project managers are responsible for the overall communication regarding the project (not just the development portion of the product). They’re the primary single authoritative source of information to ensure a shared understanding of all parameters:
    • Scope
    • Cost management
    • Timing
    • Assumptions / constraints
    • Risks / issues
    • Resources
    • Quality
    • Special considerations / exceptions
    • Development methodology considerations
    • Team members and associated roles and responsibilities
    • Policies and procedures

So, if you agree with all of the above, is there really a debate between the two roles?

There’s no way, going through Scrum Master training that I could be responsible for all the responsibilities of a project manager. It’s just not fathomable and would lead to ultimate project failure. To set the record straight, project manager is NOT synonymous with Scrum Master. A Scrum Master is critical to the facilitation and execution of the Scrum team. But they’re not responsible for all the components of a product development project. If anything, a Scrum master should be a dotted line to a project manager as part of the reporting structure. 

However, for all these relationships to work together, we also need to know what the responsibilities are of the team back to the project manager.

Essentially, the project manager has to know just about everything that’s going on during the course of a project in order to determine if the right action and the necessary progress is being made against the tasks and deliverables. It’s unrealistic for every meeting and every action to be in the project manager’s schedule. However, they still need to know what meetings are occurring and when communication and decisions are expected in order to ensure the team is working effectively and efficiently relative to the agreed upon scope and success criteria of the project.

This relationship between the project manager and the team is not meant to be based on command and control, but rather based on trust and optimizing collaboration. If the project manager has any chance in managing these responsibilities while not having authority over most, if not all, of the team resources, then they need to rely on those team leads for basic and fundamental information. The following are the characteristics of the entire product team including the project manager:

  • Openness regarding truthful task and deliverable progress
  • Frequent and constant communication
  • Commitment to achieving the success criteria
  • Courage to tell the truth
  • Respect for each other

Borrowing the page of Scrum team responsibilities to the product owner and scrum master, I’ve tailored the responsibilities so that they reflect the entire project team relative to the project manager:

  • Communication regarding the prioritization (and change) of requirements, MMF’s, sprint backlog items, and tasks
  • Commitments to results based on agreed upon milestones
  • Communication of estimates of effort to implement User Stories and tasks to complete all project deliverables
  • Communication of dependencies between tasks and team members
  • Identification of obstacles and informing the project manager when those obstacles may occur and when they have occurred.
  • Self-organizing – Individual teams within a project have to be self-organizing and can’t rely on a command and control style project manager. However, self organizing means informing the project manager on how the team is self- organized and how they intend to complete the work. Project manager’s need to have context for any of this to make sense.
  • The team has the right to do everything within the project guidelines boundaries to achieve the project goals.

In the product development world, project managers, more than ever, are critical in the successful execution and delivery of projects/products to market. Role clarity and collaboration is essential. The project manager and the scrum master are meant to work collaboratively with each other not against each other. If we can get our definition of a project correct and we can enforce the responsibilities of the team back to the project manager, then I can say confidently “Project managers, there is no need to worry about job security. You’re still a valuable member to your organization. If anything, your job just got easier by the introduction of the scrum master and product owner roles.”  Happy delivery!

Don’t forget to leave your comments below.

[1] The Study of Product Team Performance, 2012, Actuation Consulting LLC and Enterprise Agility Inc. 

A Question of Credibility: Why are Project Managers Afraid to Stop Projects?

In a recent study, the Accept Corporation and the Association for International Product Marketing and Management (AIPMM) found that more than 60% of executives say they struggle making kill/go decisions.[1] For some reason there is a tendency to continue projects and activities even when most people involved realize it’s not an optimal use of their time. Organizations generate a cultural momentum that, like a battleship, won’t turn easily or quickly even when the product team is aware of the issues. What causes this culture to develop? Are poorly aligned project incentives causing a proliferation of this behavior?

 Let’s look at some additional data to help shed light on this issue. In another recent study, The Study of Product Team Performance, 2012, [2] Actuation Consulting and Enterprise Agility found that:

  • Only 33% of product teams have daily priorities that are “strongly aligned” with the organization’s business strategies
  • Only 12% of respondents report on-time, on-scope, on-budget performance
  • Only 28% of respondents report “hit or miss” or “miss more than we hit” performance

This study also discovered that critical gaps exist in many organizations. These organizations lacked elements such as a multi-year product strategy and product portfolio management. 

From these findings, one could infer that most product development teams are working on projects that are not strongly aligned with their organizational strategy and have a strong likelihood to miss expectations. Can part of the reason be that teams are working hard to deliver projects but do not truly understand the nature of those expectations?

So often, after being assigned to a project, project managers try to run before they walk. This is especially common when the project is already in progress. You can quickly get caught up in the momentum of work and forget to question whether the work is justified. If this is truly the case, shouldn’t more projects be stopped? Aren’t project managers in the best position to go against this grain and make the recommendation to stop a project even when it’s not the most popular decision? Maybe the question should be: Would a project manager be afraid to stop a bad project even if it was the “right” thing to do but it meant losing his/her job?

What About the Project Management Code of Ethics?

It’s well documented that otherwise ethical individuals can be enticed to “bend the rules” because of poorly structured incentives. We’ve all probably seen some form of this behavior playing out in our organizations and product development projects. Whether it’s the business unit head who pushes an inadequately prepared team to reach a project go-live date in the interest of receiving a very large bonus, or a product manager trying to meet a roadmap item date but only delivering 50% of the customer’s requirements because incentives were linked to the delivery date and not the scope. Most of the time, this behavior is not meant to be malicious, but let’s face it, poorly aligned priorities linked to financial rewards can encourage individualist behavior in even the most ethical person. I honestly don’t think project managers are any more or less susceptible than any other profession to this type of behavior.

However, as a credentialed project manager, our behavioral conduct is governed by our Code of Ethics and Professional Conduct. Our code should provide us the clarity and direction we need when situations get confusing or conflicted — and projects need to be stopped. Let’s look deeper into our project management code for guidance.

Chapter four, Fairness, specifically states the following: “Fairness is our duty to make decisions and act impartially and objectively. Our conduct must be free from competing self interest, prejudice, and favoritism.

4.2.2 We constantly reexamine our impartiality and objectivity, taking corrective action as appropriate.

Comment: Research with practitioners indicated that the subject of conflicts of interest is one of the most challenging faced by our profession. One of the biggest problems practitioners report is not recognizing when we have conflicted loyalties and recognizing when we’re inadvertently placing ourselves or others in a conflict-of-interest situation. We as practitioners must proactively search for potential conflicts and help each other by highlighting each other’s potential conflicts of interest and insisting that they be resolved.[3]

And Chapter five, Honesty, states that:

“5.2.3 We provide accurate information in a timely manner.

Comment: An implication of these provisions is that we take appropriate steps to ensure that the information we’re basing our decisions upon or providing to others is accurate, reliable, and timely. This includes having the courage to share bad news even when it may be poorly received. Also, when outcomes are negative, we avoid burying information or shifting blame to others. When outcomes are positive, we avoid taking credit for the achievements of others. These provisions reinforce our commitment to be both honest and responsible.[4]

One could argue that our code doesn’t explicitly say “stop a project when it is bad” or that in certain cases the code is too aspirational — a topic for another day. But clearly it’s in our code of ethics that we, as project managers, need to make these tough recommendations to our stakeholders. So, why aren’t more projects being stopped?

What criteria do project managers use to determine if the project is off the rails with no sign of recovery? What happens if the project delivery is sound but the overall product strategy is flawed? Is it the job of the project manager to stop the organization from making this investment mistake even if he or she can deliver the project on time, scope, and budget?

If the reason that the project is “bad” can be attributed to tangible areas where the project will not meet stakeholder requirements (e.g., cost, time, scope), then it is the responsibility of the project manager to alert the sponsors so that the scope/requirements can be changed or the project cancelled. This, in fact, is one of the reasons you’re hired into the role of project manager.

However, in the case of a sub-optimal product strategy, some may interpret our loyalty mentioned in our code of ethics as loyalty to the project and the project charter, not necessarily to the common good of the organization. Some might argue that a great strategy executed poorly will almost certainly lead to failure; whereas a poor strategy, executed properly will likely have some measure of success. Once a project has been commissioned, the project manager’s focus is to execute according to the project charter. Presumably the sponsors (organizational management) are aware of strategic alternatives and, for better or worse, have chosen the project you’re working on. The current mantra is to accept this charter and execute it to the best of your ability.

As a project manager, you should be brutally honest when the viability of a project is in question, even if the concerns are regarding the product strategy. The reasons for this are important. For example, if the project no longer aligns with the strategic objectives of the organization, continuation will lead to wasted financial and human resources thereby undermining the organization’s credibility in the market. In this case, look for alternatives that could leverage the investment already made and provide value through a different, better-aligned project initiative.

So How Do You Define Success?

When creating, developing, and delivering a product to the market, we seek to maximize its value. In product development projects, the project manager typically collaborates with the product manager to construct detailed statements (success criteria) that are clear and measurable, focused around the areas of scope, schedule, and cost. Then, during the course of the project, the project manager forces the product manager to make decisions and tradeoffs against the three, but based on what? Does the product manager really understand what they’re being asked to trade-off against? The answer should be value.

Project Managers need to adjust their perspective around scope, schedule, and cost and relate it back to what the overall value is of the project. When you make this adjustment you realize that the balance of scope, schedule, and cost is more of an equation based on deriving value. I call this the project management value equation. It’s designed to give context to “scope, schedule, and cost,” ensuring that you’re weighing all that you do against the overall value of the project and keeping your product manager and product team focused on the prize. Said another way, it’s an equation meant to quantify and assess the value of a project and identify — if value has been decreased — whether the project should be stopped. The equation is (working model identified in book):

Value = Scope ÷ (Schedule + Cost)

By understanding this concept, you bring more depth and meaning to what you really need your product manager to trade off against. By assigning a value to each of your success criterion, you in essence are quantifying the value of the project. Remember, good project managers know that project success is not whether it’s delivered on time and within budget, but whether it delivers value and meets the defined success criteria.

Our project success criteria should then be evaluated using our code of ethics. Ask yourself, “are the intentions of the project feasible and ethical?” “Am I willing to act in an ethical way, to complete the project — even if completion means stopping it?” It’s likely that the project sponsor views this recommendation as a personal attack and the result turns out to be a career-ending move. In a tough economy, stopping a project becomes an extremely difficult decision. However, I still hold the position that, based on our code of ethics, the answer to the question…should a project manager stop a project even if it means losing their job…should be YES! When managing a product development project, our Code of Ethics is the backbone to our credibility — and sacrificing our credibility should never be an option.

Don’t forget to leave your comments below.


[1] Accept Corporation and Association of International Product Marketing and Management (AIPMM). PPM is Dead. Long Live Portfolio: Q2-2011 Study – Portfolio Management Priorities. June, 2011. Retrieved from

[2] The Study of Product Team Performance, 2012, Actuation Consulting and Enterprise Agility, March 2012

[3] PMI Code of Ethics and Professional Conduct ©2012 Project Management Institute, Inc

[4] PMI Code of Ethics and Professional Conduct ©2012 Project Management Institute, Inc

About the Author:

 Steven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Thomson Reuters and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development.