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

Why does everyone despise software estimates?

Is it because …?

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

… it is hard?

… people often get it wrong?

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

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

Everything starts with our own point of view

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

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 …

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.

Who we actually are …

Who we actually are … We make things done.

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

… and these are risks and uncertainties the client faces …

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

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

/ 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

Introduction

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.

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 /

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

Section 1: How to get context and relevance

/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.

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?

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

/ 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.

/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.

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

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

/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

/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”

/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

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.

Section 2: How to manage risk and uncertainty

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

/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.

/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

/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.

/Extended use cases

/Extended use cases

/Extended use cases

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

Section 3: How to become an agent of change

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

● 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

/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%.

/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.

That’s it we’ve made it …

Conclusions

/ 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.

Thank You! and we are hiring!!