Contact

Shifting from Project to Product 

    A structural change from Project/Silos to Product/Networks is necessary for agility. 

    There has been plenty written over the last year about the need to shift from the world of projects to product-based development. These people – some of whom I provide links to in the further reading below – give compelling reasons for teams and businesses to begin to think about structuring work and engagements in terms of products that are managed rather than projects that are delivered. Here’s my perspective on this topic as it relates to the work I have done with large organizations as a coach and consultant. Let’s start by defining the difference between a project and a product.

    So what is the difference between a project and a product?

     

    Here is the definition of a project provided by the Project Management Institute (PMI):

    A project has a defined beginning and end in time and is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal and often includes people who don’t usually work together. At the end of a project, the team is usually disbanded and assigned to new projects with new team members.

    On the other hand, a product is a good, service, platform, application, system, etc. that is created, maintained and supported by solving problems and providing benefits to specific customer and business needs. Products tend to be maintained by a stable group of individuals who do work together regularly and who bring in others as needed.

    Major shifts in mindset are needed to move to from projects to products that support a Lean and Agile way of thinking.

     

    See the text version below.

    Focus Area Project Mindset Product Mindset Reason Groupings
    Lifecycle

    “One & Done”

    One-time phases might be grouped into larger programs with clear stop & start dates.

     

     

    “Ongoing Evolution”

    Continuous, iterative and incremental loops of Plan-Do-Check-Act

    Quick and ongoing feedback loops allow organizations to adapt short-term needs while moving towards long-term goals.

    Focus & Flow

    Optimization

    “Follow the Person”

    Resource efficiency focuses on each individual/team and maximizing hours available.

     

     

    “Follow the Work”

    Flow efficiency focuses on throughput and delivery of value across teams, and on minimizing waste.

    Optimizing the whole system connects and aligns the overall organization for greater flow of value delivery.
    Work Structure

    “Break down effort”

    Big plan / project placeholders are broken down into smaller pieces.

    “Build up value”

    Small experiments lead to minimal viable solutions achieving incremental goals on a roadmap towards an inspiring vision.

     

     

    Big plan upfront gives the false sense of security around the problem-solution fit, often leading to failed projects or successful projects achieved way out of scope (time, money, etc.).
    Outcomes

    “Inward Focus”

    The focus is on Solutions/Systems – how to build, what to work on, what the system needs, etc.

    “Customer Focus”

    The focus is on the Customer – what to deliver and why. Simulating & identifying valuable experiences is key.

    In a volatile market with fierce competition, improving your system can only get you so far. The winning approach is to improve your system according to the ever-changing needs of the market and your specific customer.

     

     

    Customer & Business Value

    Performance

    “Follow the Plan”

    The mantra is “On time, on budget, on scope.”

    “Deliver Value”

    The sweet spot is at the cross-section of:

    -Feasible – Can we do it?
    -Valuable – Do customers need it?
    -Desirable – Does it serve our business?

     

     

    Artificial project targets that are not tied to customer value historically lead to underwhelming performance in the market and affect brand promise and loyalty.
    Requirements

    “Order Taking”

    The project team waits for orders from stakeholders and focus on documenting wants of the solution, while rarely interacting with the end user.

    “Problem Solving”

    Product teams discover problems and needs through user interaction, with user stories as placeholders for conversations.

     

     

    Saying “no” to ideas that aren’t solving real problems and needs will make room for requirements that have been validated early in the process before investment in a solution.
    Key Metrics

    “Get it Right”

    – Change to Plan
    – Estimates vs. Actuals
    – Bug Counts

    “Learn & Improve”

    – Cycle Time
    – Flow/Work in Progress (WIP)
    – Time to Fix

     

     

    Traditional metrics give the semblance of data but improvement in these areas rarely improve product sales or reception.

    Feedback & Learning

    Reporting

    “Up the Ladder”

    Status, spend and risk are reported to management who then interpret and report to their management, and so forth.

    “Multi-directional feedback”

    Delivery, value and impediments are radiated in all directions through demos, conversations, visualizations, etc.

     

     

    The unilateral reporting structure of traditional project management often hides real business risk, because work is often messy. The view gets rosier and rosier as you go up each rung of the ladder.
    Risk

    “Upfront Analysis”

    One big, comprehensive assessment seeks to identify and mitigate all possibilities of risk.

    “Just-in-time Resolution”

    Analysis upfront has a small scope – just enough to get a pilot started. Impediment resolution happens frequently through check-ins and synchronization across teams.

     

     

    Often upfront assessments go looking for the infinitesimal risks that could lead to litigation and gloss over the real risks that happen in every project.
    Leadership

    “My Team”

    Leaders assign managers, teams and individuals to projects and tasks. Accountability is only felt at the top.

    “One Team”

    Self-organizing teams pull in work based on capacity, supported by servant leaders who foster collaboration and agility.

     

     

    When accountability is concentrated in leadership, reports don’t buy into the process or feel they contributed to the success. Further, leadership rewards continue to climb while everyone else’s stagnate.

    Collaboration & Teamwork

    People

    “Interchangeable Resources”

    People are exchangeable, individual contributors that can be moved from project to project or across projects. Expectations about deliverability do not change when individuals are switched in and out.

    “Team Members”

    People are part of dedicated and persistent teams, working in pairs or swarms where possible. When individuals need to be switched in or out, the team re-assesses capabilities and adjusts goals accordingly.

     

    The staggering rate of disengaged and actively unengaged workers reported by the US Department of Labor makes sense when you understand two things: 1) people have their own internal drivers (and 2) money can only motivate an individual to a certain extent. The key is that ownership in results can ignite passion in individuals and teams in ways that money alone cannot.

     

     
    Governance

    “Stick & Follow”

    Detailed standards, checklists, templates and review ensure people follow the “right” process.

    “Pragmatic & Adaptive”

    Minimally sufficient guard rails for consistency are setup and revisited in real time as needed. This is often industry specific.

    Rigid governance makes it difficult to adapt to real-time feedback. People feel disempowered to make impactful decisions and so keep their head down.