Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Let’s burst our bubble: projects, products, estimates and forecasts. - Tassos Koutlas

Let’s burst our bubble: projects, products, estimates and forecasts. - Tassos Koutlas

In every community event for the past 10 years, there has been a presentation about the software estimation process. Discussing whether estimates are an art or a science, best practices, why they go wrong, and presenting interesting ideas such as the no-estimates movement. There seems to be an abundance of information on the subject, yet, the debate is far from over. Software estimation, despised by many, is one of the most contentious subjects, constantly coming up in conversations between developers, project managers, product managers, clients, budget holders, and stakeholders.

This talk is split into 3 sections.

In the first section, I will discuss the nature of modern application development and, in particular, two approaches: project-centric and product-centric application development. I tie those into the modern B2B purchase journey that represents enterprise application development so that participants get an understanding of the end-to-end process: from budget setting to application conception to delivery to decommission and how this influences everyone involved.

In the second section, I draw from my experience being part of the Digital Solutions team in FFW, where I am picking up technical pre-sales activities for new projects. Part of the job is to provide budget indication during the RFP process, the worst possible moment because it’s the moment we have the least amount of information about the work at hand. I will present some of the techniques and best practices I have used to quantify effort, manage risk and minimize uncertainty.

Finally, in the third section, I will dive into suggestions for aspiring agency teams that would like to encourage their clients to shift from project-centric development into product-centric development. Specifically, I will discuss the behaviors that should be adopted internally to instill trust in the client, changes that need to be made for successful delivery, and early warning signs to evaluate if you are on the right track.

At the end of this talk, participants will get an understanding of:

The differences in processes and expectations for project-centric and product-centric application development
End to end modern B2B purchase journey which represents enterprise application development
The best practices for budget estimation for project-centric application development
The best practices for budget estimation for product-centric application development
Suggestions for product-centric enablement internally and at the client

WordPress Greek Community

April 09, 2022
Tweet

More Decks by WordPress Greek Community

Other Decks in Technology

Transcript

  1. 9 March 2022
    Let’s burst our
    bubble
    Projects, products,
    estimates and
    forecasts

    View full-size slide

  2. Why does everyone despise software
    estimates?

    View full-size slide

  3. Is it because …?

    View full-size slide

  4. … it creates so much friction
    between developers, project
    managers and clients?

    View full-size slide

  5. … it is hard?

    View full-size slide

  6. … people often get it wrong?

    View full-size slide

  7. … it makes it easy to blame people if
    the project overruns?

    View full-size slide

  8. And even then, how can we accomplish it?
    Big estimate upfront?
    Estimation poker?
    Spreadsheets?
    Story points?
    Abandon it all together → #noestimate?

    View full-size slide

  9. Everything starts
    with our own point
    of view

    View full-size slide

  10. This is Odysseus, hero of Homer’s Odyssey and Iliad.
    Thought to be the smartest person on Earth.

    View full-size slide

  11. This is Odysseus, hero of Homer’s Odyssey and Iliad.
    Thought to be the smartest person on Earth.
    In a client project this is who
    agency people think we are …

    View full-size slide

  12. This is Odysseus, hero of Homer’s Odyssey and Iliad.
    Thought to be the smartest person on Earth.
    In a client project this is who
    agency people think we are …
    … whilst this is the client’s
    team.

    View full-size slide

  13. Who we actually are …

    View full-size slide

  14. Who we actually are …
    We make things done.

    View full-size slide

  15. Who we actually are …
    We make things done.
    The client is the hero.

    View full-size slide

  16. … and these are risks and
    uncertainties the client faces …

    View full-size slide

  17. … and these are risks and
    uncertainties the client faces …
    We are enablers and our job is to make
    clients reach their destination, uneventfully!

    View full-size slide

  18. Thinking we are the hero clouds our judgement.
    1. Makes us be out of context and often out of place.
    2. Inhibits us from managing uncertainty and risk effectively
    3. Keeps us from becoming agents of change for our customers
    So what can we do about it?
    /Focus

    View full-size slide

  19. /
    How to get context
    and relevance
    Thank you!
    A question
    first …
    How to manage risk
    and uncertainty
    How to become
    agent of change
    `
    Conclusions
    Our agenda today
    Intro

    View full-size slide

  20. Introduction

    View full-size slide

  21. Who am I?
    Tassos Koutlas
    Deputy VP Digital Solutions
    Europe
    Provide a unique,
    objective, and
    specialised approach
    on how to leverage
    business success
    through technology.
    A subject matter expert in digital transformation, agile, technology and
    communications. Currently working as Deputy VP of Digital Solutions Europe for
    FFW, which offers strategy, design and technical implementation services for digital
    projects.
    I adopt a proactive, problem solving approach and brings an entrepreneurial mindset
    based on pragmatism, creativity, openness and innovation. I have many years
    experience creating digital strategies, architecting complex digital solutions and agile
    coaching in Europe, Americas and Asia.
    Over the years I have worked with a great number of enterprises, governments and
    non-profit organisations such as: Pfizer, Alcon, Panasonic, Nestle, Keller, Finastra,
    Hiscox, Museum of Modern Art in New York, Southbank Centre, Barbican, World
    Health Organization, Médecins Sans Frontières, University of Cambridge and many
    others. He has also launched several businesses.
    I have a PhD in Artificial Intelligence (Machine Learning and Machine Vision in
    particular) from the University of Ioannina and a B.Sc. in Computing Science from the
    University of Manchester.

    View full-size slide

  22. Global scale, local presence - working as one
    ● United States
    ● United Kingdom
    ● Denmark
    ● Germany
    ● Moldova
    ● Ukraine
    ● Vietnam
    ● France
    ● Sweden
    ● Bulgaria
    FULL TIME
    EMPLOYEES
    650+ 21
    YEARS
    EXPERIENCE
    25
    OFFICES
    WORLDWIDE
    TECHNOLOGY
    SPECIALISTS
    400+ 500+
    CLIENTS
    SERVED
    2000+
    SOLUTIONS
    DELIVERED
    100%
    OF CUSTOMERS AWARDING
    US A FIRST PROJECT…
    AWARDED US A SECOND
    /

    View full-size slide

  23. Take a deep breath and let’s go for it …

    View full-size slide

  24. Section 1: How to get context and
    relevance

    View full-size slide

  25. /The two mindsets
    From automating process in the 60s till the 80s, to system integration through the 80s to 00s
    anywhere you looked some kind of project was underway. Since the early 10s we increasingly hear
    about platforms, continuous improvement of software capabilities, agile transformation that are
    resembling the continuous nature of product development. This creates two mindsets.
    Product-centric
    A product is an
    aggregation of business
    capabilities that is
    consumed by the business
    organization. The product
    has exclusive budget, a life
    cycle and dedicated team
    which delivers product
    capabilities over time.
    B
    Project-centric
    A project is a collection of
    new or modified business
    capabilities. Sometimes
    they must be delivered at
    one time; in most cases,
    only some of them are
    critical and only some
    need to be delivered at
    the same time.
    A
    How budgets are
    set, effort is
    estimated, progress
    is tracked, results
    are evaluated
    differs greatly
    between those two
    mindsets.

    View full-size slide

  26. The need comes from digital transformation:
    A. either create advantage within core markets through
    innovative digital features that complement existing products
    or services
    B. or create new digital products or services that extend the
    enterprise into new or adjacent markets
    Both increase the need to transform the organisation and be
    focused on digital innovation. This shift is analogous to creating
    a product-centric organisation and thus an agile organisation
    with changes in structure, skills and culture.
    /Why is Project getting ditched?

    View full-size slide

  27. However product-centricity is hard
    and there are many organisations
    that still struggle with the transition

    View full-size slide

  28. /
    Project characteristics
    Product vs project
    Product characteristics
    Funding for life of project
    (based on resources and time)
    Work stops at a fixed date
    Change is avoided
    Focus on plan
    Tracked by project variance
    Funding for life of product
    (based on business need)
    Work stops when product
    retired
    Change is embraced
    Focus on features
    Tracked by business value
    Product mindset looks very close to agile, however product-centricity is not just about delivery. It also contains
    governance characteristics such as funding terms, progress tracking and investment retirement.

    View full-size slide

  29. /How can you tell if you are working
    in/with a product-centric organisation
    A product manager manages and organises how new features come about to
    the product. Product owners then represent product vision to the dev teams.
    An established product roadmap is used to organise and prioritise demand
    related to business capabilities.
    Investment governance process uses the roadmap to allocate resources to
    various products (essentially prioritising how quickly the roadmap is executed).
    Product managers work together with architects and developers to size the
    work based on past experience to fit into release development window.
    Emphasis is given to business outcomes which are measurable improvement
    of a business capability with financial benefit associated with it.
    The primary objectives associated
    with product leadership are:
    ● Rapid, technology-infused
    product/service development,
    testing and delivery
    ● Improved customer
    engagement and delivery
    channel evolution
    ● Establishing and maintaining
    competitive advantage
    ● Creating scale
    ● Revenue growth
    Focus is on integrating evolving digital technologies and ascertain their
    priorities with self-organising teams and iterative delivery.

    View full-size slide

  30. If you are not working in/with a
    product-centric organisation then none of the
    agile ways to set budget, manage scope and
    track delivery will work.
    By design.
    The client expects to know which resources
    will deliver which part of the scope, when, and
    for how much. That’s how projects get tracked.
    /Expectation management

    View full-size slide

  31. Even product-centric clients, ask to
    set budget expectations upfront,
    before purchasing decisions …

    View full-size slide

  32. /That’s because the B2B purchase journey
    is not linear
    There are six B2B buying
    “jobs” that customers must
    complete to their satisfaction
    in order to successfully finalize
    an actual purchase.
    Customer surveys show that
    B2B buying doesn’t play out in
    any kind of predictable, linear
    order. Instead, customers
    engage in what we might call
    “looping” across a typical B2B
    purchase, revisiting each of
    those six buying jobs at least
    once.
    Budget expectations can shift
    based on those stages.
    1 2 3 4
    5
    6

    View full-size slide

  33. /B2B
    purchase
    journey
    map
    Buying jobs don’t
    happen
    sequentially but
    more or less
    simultaneously.
    And if we were to
    map out a real
    B2B buying
    journey, it would
    look a lot less like
    a step-by-step
    linear process
    and lot more like
    a big bowl of
    spaghetti.
    * Potential budget altering “jobs”

    View full-size slide

  34. /To recap:
    ● Many engagements don’t follow
    product-centric tactics to manage budget and
    thus a way to estimate software is needed
    upfront
    ● Even when they do, they rarely allow first time
    engagements to set budgets in agile ways,
    requiring to estimate software upfront
    PM + UX + UI + BEx3 + FEx2 + QA + DEVOPS

    View full-size slide

  35. Essentially leaving us like this …
    If only, there was a technique to incorporate uncertainty, while not
    knowing precisely the details and durations of all the activities.

    View full-size slide

  36. Section 2: How to manage risk
    and uncertainty

    View full-size slide

  37. What does Poseidon, submarines
    and managing risk and uncertainty
    have in common?
    It’s not Odysseus …

    View full-size slide

  38. /Meet the United States Navy Special Projects Office
    ● It Is a method of analyzing the tasks involved in completing a given
    project, especially the time needed to complete each task.
    ● It incorporates uncertainty by making it possible to schedule a project
    while not knowing precisely the details and durations of all the
    activities.
    ● It is more of an event-oriented technique rather than start- and
    completion-oriented.
    ● It is used more in projects where time is the major factor rather than
    cost (and those where cost comes up from time).
    ● It is often applied on large-scale, one-time, complex, non-routine
    infrastructure and on Research & Development projects.
    PERT
    The U.S. Navy Special Projects Office in 1957, developed a method to simplify the planning and
    scheduling of large and complex projects. The method was called PERT short for Program Evaluation
    and Review technique.
    In short
    United States Navy Special
    Projects Office (SPO) is a
    former research and design
    office of the United States
    Navy, responsible for the
    coordination of the
    development and design of
    the US Navy Fleet Ballistic
    Missiles (FBM) Polaris and
    Poseidon.

    View full-size slide

  39. /Theory and application
    ● Estimate optimistic time - the minimum possible
    time, assuming everything proceeds better than is
    normally expected
    ● Estimate pessimistic time - the maximum possible
    time, assuming everything goes wrong (but
    excluding major catastrophes)
    ● Estimate most-likely time - the best estimate of
    time, assuming everything proceeds as normal
    ● Calculate expected time of project (see next)
    ● Calculate standard error of project (see next)
    ● Calculate confidence interval of project (see next)
    Theory
    ● Simple, yet highly effective method to
    incorporate uncertainty and risk that may be
    present on risks but not known at the time of
    estimate and budget setting.
    ● Estimation forces you to think about
    assumptions and risks. Best practice to note
    them and use them later with clients.
    ● Identify riskier tasks and be able to discuss with
    client ways to mitigate those risks (more info,
    discovery phase, descope, etc).
    ● Can be used with both fixed-price or range
    budgets by adjusting confidence intervals.
    PERT is also known as three point estimate technique. The theory is based on the construction of an
    approximate probability distribution representing the outcome of future events, based on very limited
    information.
    Application

    View full-size slide

  40. /An example
    Optimistic estimate (To) - best
    case scenario (i.e. all assumptions
    hold, good risks).
    Pessimistic estimate (Tp) - worst
    case scenario (i.e. assumptions
    not covered, risks introduced).
    Best guess (Tb)- most likely
    scenario based on estimators
    experience.
    Expected time (Te) - calculated
    by: (To + 4*Tb + Tp)/6
    Standard deviation (SD) - per
    task calculated by: (Tp - To)/6
    Estimated time E(project) -
    project estimated time
    calculated by: sum(Te)
    Standard error SE(project)-
    project standard error calculated
    by: sqrt(sum(SD^2)
    Simple ;)
    Estimated Calculated
    Calculated
    Calculated
    Make a copy
    Measures variability or
    uncertainty in the estimate and
    project.
    This says that 95% of the
    time the project will fall
    within this range.

    View full-size slide

  41. /Extended use cases

    View full-size slide

  42. /Extended use cases

    View full-size slide

  43. /Extended use cases

    View full-size slide

  44. OK, I know, let’s take a breath …
    So how do we move on from here?

    View full-size slide

  45. Section 3: How to become an
    agent of change

    View full-size slide

  46. How do you help a client
    organisation move from
    project-centric to product-centric?

    View full-size slide

  47. ● Comes only if there is support from top
    management. If not, don’t try, you will fail.
    ● If there is support, then you will have to convince
    all the middle layers about the validity of your
    approach.
    ● That works only if the know you, like you and trust
    you.
    ● So work the account, over deliver and be super
    easy to work with …
    /Change

    View full-size slide

  48. /Why is product-centric hard for enterprises?
    ● Organisational: Majority of project requests can best be construed as
    one-off and designed to meet immediate/short- term needs. The
    requestor is focused on an external customer or solely on fixing a
    current organisational pain. IT is immediately focused on how to make
    the request fit into its world of installed systems and planned
    architecture.
    ● Financial: Finance and auditors are very comfortable with traditional
    waterfall development using the phases of work and classifications to
    calculate capital expenditure (capex) at go live and operating
    expenditure (opex) during operation.
    ● Operational: Shifting from projects to products disrupts traditional IT
    governance, including decision rights, stakeholder roles and
    CIO-product owner engagement.
    Top-3 reasons
    In many organisations today, IT is viewed as a cost center. As such,
    the goal is to manage costs, and that has led to a dysfunctional
    funding process for applications.
    Understand budgeting
    In most businesses, the
    planning for application
    spending takes place at
    budget time; typically
    beginning in June or July of
    the previous year.
    As part of that process,
    business leaders are asked to
    determine the work
    (projects) necessary for the
    next year.
    The applications team
    creates a high-level (i.e.,
    guess) estimate. The total
    costs are then totaled and,
    regardless of their absolute
    value, are compared with last
    year's budget, plus or minus
    X%.

    View full-size slide

  49. /What can you do? Need to ensure consistency of the brand, user
    experience and coordination between teams.
    One big danger of product-centric teams is that
    they go off on their own and build inconsistent
    products using inconsistent methods.
    Hold teams collectively accountable for
    delivering business outcomes and
    customer satisfaction. Establish with the
    client KPIs reflecting those principles.
    Eliminate layers of management,
    hierarchy and seniority on your
    teams and form truly
    self-managed teams. Break up
    specialist organizations — such as
    quality, project management,
    integration, security, development
    and information management —
    and distribute those employees
    among cross-functional
    product/client teams.
    Show the client that you can provide teams
    with all the skills and expertise necessary to
    deliver applications that support a group of
    business capabilities.
    Transfer individuals slowly over time to
    start new teams, inoculate new teams with
    the new culture, and diffuse domain
    knowledge across a variety of teams.

    View full-size slide

  50. That’s it we’ve made it …

    View full-size slide

  51. / What to take home
    1. Application development is split between 2 mindsets: product-based and project-based.
    Each comes with their own rules and expectations and you should be able to understand
    under which you operate so that you can follow the work within context and relevance.
    2. For the client, vendor selection is the last step of their B2B purchase journey. By that
    time they have made up their minds in so many things which means that the probability
    of influencing is not that high.
    3. To influence the client you need to get involved in previous steps in their B2B purchase
    journey. This is very difficult to do. Successful organisations can make it happen with
    proper planning, investment in marketing/PR activities and vertical specialisation.
    4. The best investment you and your team can make is understanding how to manage risk
    and uncertainty within a given strand of work. Then it won’t matter so much if you work
    in product-centric or a project-centric.
    5. If you build enough trust with the client they will follow you anywhere. Building trust with
    the client always involves overdelivering.

    View full-size slide

  52. Thank You!
    and we are hiring!!

    View full-size slide