Let’s Rewrite the PMBOK

Future PMBOK
Phew, the wait is over! I have been wanting to talk about this for what seems like ages and now the official announcement is out! If you have ever been frustrated by the PMBOK Guide now here’s your chance to fix it.

We are looking for volunteers to write and review the next edition of the PMBOK Guide. However, this will not be just an update, instead a radical departure from all previous editions aligned with PMI’s new digital transformation strategy. That’s all I can explain for now, but more details will be announced when I can say more.

Meanwhile, we would like people with knowledge of the full value delivery spectrum (waterfall, hybrid, agile, lean, etc.) to participate.

The full details of volunteer opportunities and entry requirements can be viewed at the PMI VRMS site Here.

I will be acting as Co-Lead for the initiative, which is like a co-chair role. However, Chair and Co-Chair sounds too hierarchical so we switched to Lead and Co-Lead role to match the new structures we will be embracing.

If we want to change the future of project management I believe the best way to do that is from the inside outwards by doing the work - not from the outside inwards just criticizing. Longtime readers may recall my 2010 post Raise A Little Hell when the PMBOK v5 Update was being commissioned. Since then we developed the PMI-ACP, PMBOK Agile Appendices, and the Agile Practice Guide.

This is going to be different!

Click here to see full volunteer role details.


Review of Product Development Books

Product Development CycleNow that a software “Done” Milestone is more like a Tombstone

If you work in an industry that has digital products and services then the Product Development trend will impact you. As software becomes more critical to business operations and product offerings we are seeing that software projects do not end.

Many organizations are transitioning to become software focussed organizations that offer specialized services. Amazon is a software company with retail (and cloud) offerings. Banks are increasingly digital companies with financial services. The same with insurance, travel, music and even commercial goods. The cost of developing the software in new vehicles is now greater than the cost of the engine. It has become the single most expensive component, even in internal combustion engine vehicles with no autonomous driving features.

These websites and software services will only be “done” development when the company stops being competitive, offering new services or keeping up with technology evolution. At one time getting to "Done" on your software project was a relief, a goal, a milestone, now it is more of a tombstone. It means the product is no longer competing or actively being maintained as technology continues to evolve.

Switching from projects (that are temporary in nature) to products that are designed to be ongoing sounds easy enough - just keep funding the team, but for many organizations it is not that simple. Also, organizations that embrace the whole digital product view still need help governing the ongoing process.

This is where product development books can help. They describe the factors at play and provide ideas for guidance around planning, funding, staffing and governance. As I was working with clients experiencing the transition from projects to products I was lucky to engage with several authors of product-first, #NoProjects books and chat about the challenge areas and potential solutions.

I have written about #NoProjects a few times before:

 

Then when I recently read a third book about product development shift I thought it could be useful to review some of the books in the market. A neat aspect of these books is that they all present different views on the project to product mind-shift and journey.  

Continuous Digital

 “Continuous Digital: An agile alternative to projects for digital business

Allan Kelly, Software Strategy Ltd.; October 2018

Allan’s book was the first I read about switching to continuous product development. I had been following his blog for a number of years and was familiar with his work. However, it was not until reading the book that I saw his points laid out in order with full explanations.

It is a great read, it makes a compelling argument for why a project view of software projects is a flawed model. I loved the explanation on the diseconomies-of-scale for software and why it is actually cheaper in small batches – unlike physical goods.

It offers the best explanations I have heard into why a continuous delivery of features by a stable team is preferable to using conventional project models. It nicely describes the team aspects of knowledge work and offers some good suggestions around funding and governance models.  

Any change in mindset has to happen internally first before we can help others adopt it. Continuous Digital cemented my own thoughts about why good software projects never end. It explained the “Why?” questions at the heart of any shift in thinking and behavior. In the same way, we have to understand the agile mindset before generating any kind of commitment towards it. This book helps set the mindset and Why of #NoProjects so we can start our journey.

 

Noprojects book#noprojects: A Culture of Continuous Value

Evan Leybourn, Shane Hastie, lulu.com; July 2018

I read an early draft of Evan and Shane’s #noprojects about 6 months after I started reading Allan Kelly’s LeanPub drafts of Continuous Digital. While Kelly’s Continuous Digital and his spin-off book Project Myopia focus on explaining the Why with some How topics, #noprojects has more of a team focussed view.

It talks about the history of software development. It explains how we came to run software development with project structures and the inherent issues that came with them. It then outlines the case for continuous development with all the arguments for retaining knowledge, reducing handoff and dependences, etc.

I think it is a great follow-on from Continuous Digital. Obviously, it is designed to be a stand-alone text but, for me, Kelly explains the Why of product development better. Then #noprojects fills in some additional background information and focusses more on the team level implementation. It might just be because I read Kelly’s book first but if you are looking to convince others in your organization about the need for transitioning to product development it is the go-to source. Reading both will provide a great foundation to understand and transition from projects to products.

 

Project to ProductProject to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework

Mik Kersten,  IT Revolution Press; November 2018

I first came across Mik’s work via a podcast he did with Shane Hastie. In the podcast, Mik explained that technologies often follow 50-year cycles and then transform through a tipping point into the next evolution in the way of working.

Organizations that try to continue operating with the old model flounder and fail. Moreover, it is now about 50 years since NATO held the first conference on software engineering and the age of software began. Mik explained he believes we are at that tipping point and transitioning to product delivery will be part of the differentiator for the next wave of successful organizations.

I have an interest in technology evolution stories and learning how ideas spread and then transform our lives. So, the 50-year cycle piqued my interest and I ordered the book. The book delivers and not only does it explain the tipping point we are living through right now, but it gives the best explanation of the digital revolution and need for digital transformation I have read to date. Kudos to Mik. If you want to explain why a digital transformation is necessary, and the implications of ignoring it, Project to Product is a brilliant source.

After this great introduction, the remainder of the book explains the Flow Framework Mik helped develop and promotes through his company Tasktop Technologies. The Flow Framework provides metrics and tools for tracking and managing product development. This is useful because while the project management world has a wealth of information about tracking and managing projects, organizations that switch to product management often experience a void or competing recommendations.

The Flow Framework is useful for explaining what we should pay most attention to tracking. Namely features, defects, risks and debts. It recommends a business outcome set of measures that include: value, cost, quality and happiness. The framework employs a lean inspired set of metrics that include flow velocity, flow efficiency, flow time, and flow load.

It is in the rebranding of tradition lean metrics that I struggle to recommend the book wholeheartedly. By prefixing the normal throughput based lean metrics with the word “Flow” Mik is able to define  specific versions of the terms that are often implemented slightly differently from organization to organization. I can see the advantage of that, but it seems an unnecessary name-grab or overloading of lean terms to create trademark-able terms.

That’s a minor quibble though and what Flow Framework does provide is a good mental model for organizing, executing and tracking your product development process. It nicely extends the pattern of books started with Continuous Digital that explains Why product development. Then #noprojects that provides some team-based and stewardship elements. Finally, Project to Product provides solid How To ideas for ongoing governance and improvement.

 

Summary

These three books form a useful progression for anyone wanting to learn about the product development trend. They each provide valuable ideas to help with understanding, practicing and then managing successful product delivery.

Product Development Books Progression

The books allow readers to understand and internalize the need for a product development mindset. Then how to practice on a small scale before encouraging others to try and providing ways to measure and manage it.

Obviously, you do not need to read all three of them, or in this sequence. Any one of them is a good read and source for practical ideas. However, I found that they build nicely upon each other and thought people would be interested to consider them as complementary.


Agile 2018 Conference – Unraveling Team Dependencies

Agile_SD2018_600x100_Speaking_FM
I am excited to be presenting on the Enterprise Agile track at the Agile 2018 conference in San Diego, August 7. I have worked with several organizations this year that had issues with work dependencies between teams. My session called “Two-Pizza Team Heartburn Relief: Solutions to Team Dependencies” highlights the shift to global rather than local optimization.

We will investigate dependency problems through animations and simulations and then explore some candidate solutions. Each brings their own issues – if these problems were solvable they would have been already, but the suggestions do help considerably. Here is the description from the conference program:

Small teams are great - until they cause bigger problems than they solve. Small teams can communicate more effectively than large teams. They can leverage face-to-face communications more readily and share tacit knowledge without the need for so much written communication. However, for large endeavours, using many small teams present their own problems. Work dependencies between teams can cause major delays through costly hand-offs, mismatched priorities, and blocked tasks.

This workshop introduces strategies for structuring teams to reduce hand-offs and dependencies that create blocked work and delays. By investigating the (lack of) flow through multiple teams we can diagnose the cost of hand-offs and culprits of delays. We examine tools for making hand-offs and dependencies visible to highlight and bring collective attention to the problems. We then explore resolution patterns and work structures that maximize small team communications but limit negative aspects of managing multiple, inter-dependent project teams.

Learning Objectives

  • Understand the time and cost penalties of team dependencies and hand-offs
  • Gain tools for making dependencies, queues, and blocked work visible
  • Learn how and when to balance small team benefits with more dependency issues
  • Share implementation patterns and strategies to maximize team throughput
  • Examine the pros and cons of larger teams, feature teams, and product vs. project development.

That probably sounds more technical than it really is. It is a workshop to show people how teams often get stuck with work items when they rely on work from other groups. It combines anecdotes and experiences from 20+ years of agile consulting along with some insights from Troy Magennis on dependency delays, and Dominica DeGrandis, author of Making Work Visible.

Through case studies and exercises, we explore the hidden impacts of well-intentioned small teams. First, we’ll explore the “mostly harmless” two and three team dependencies, and then see the impacts when five or six dependant teams try to get work done. Please come along if you are attending the conference and have issues with dependencies between teams.


The Truth About Transformations

TransformationTransformations are flavor of the month. It is no longer enough to launch “initiatives,” “programs” or “projects” to undertake work. Instead, we launch agile transformations, digital transformations and productization transformations. They sound more revolutionary, more dramatic and further reaching. Our organizations will emerge reborn, uniquely positioned to compete in a new world of opportunities and growth. Like a larva transforming into a butterfly, we can now fly!

Well, that’s the idea and the promise of the consulting companies that sell transformation services. However, what really happens? Can the average organization actually become a disruptive leader just by adopting the structures, tools and processes from the real disruptive leaders? Or, is it like buying the same shoes as our basketball heroes wear hoping they will transform us into slam-dunking superstars? The reality is somewhere between these extremes. Any company can improve, but we should not expect to become something we are not.

Let’s look at some of the popular transformation services on sale and examine the promise and truths they hold.

 

Agile Transformations Dandelion

The goal: Agile transformations move organizations from working with traditional project management approaches to using agile approaches. They also seek to change the way organizations are structured and run from a top-down, command-and-control model to a more business- and customer-led, value-driven approach.

They aim to instil lean concepts of respect for people, minimization of waste, and value delivery. They employ a more trusting Theory Y view of workers as willing contributors rather than the traditional Theory X view that workers need close supervision to work hard. They encourage workers through intrinsic motivators such as empowerment, autonomy of work, and belief in a worthy purpose rather than carrot-and-stick approaches.

The claimed benefits: Agility allows organizations to respond to change more quickly since plans and work are done in smaller batches with frequent checkpoints. This allows changes in direction to be made when feedback indicates it would be desirable. The evaluate-as-you-go and learn-as-you-go aspects of iterative and incremental development help organizations manage complexity and uncertainty.

Agile approaches allow for the delivery of value sooner since work is prioritized via business value. The empowerment and intrinsic rewards offered result in happier, more engaged employees. Allowing workers to design their own workplace and work practices results in a more loyal and productive workforce. A mantra of one agile approach is to “Change the world of work.”

The reality: Agile is much easier to implement at a team and project level than it is at an organizational level. Teams quickly see the benefits of frequent collaboration and business engagement. Tools like product backlogs, kanban boards and release roadmaps bring much-needed visibility to design work and problem solving that often manipulates invisible data and ideas. Iterative development of small batches of work, with frequent reviews, provides better insights into progress and issues than sequential, large-batch development. While some people find the “let’s try something” approach counter-intuitive to rigorous upfront planning and design, most understand the risk reduction and true requirements validation benefits.

At the organization level, it’s a tougher sell. The initial confusion and apparent chaos that comes with establishing empowered, self-organizing, self-managing teams can seem like the inmates are running the asylum. What happens to supervisors and managers? In some organizations, departments are built around functional silos. If I was head of the quality assurance group and now all my people report into individual teams, what’s left for me to do? How do I justify my yearly budget (and position) with my headcount down to zero?

Organizational structures often reflect their culture and decision-making style. This may be hierarchical, flat or distributed. Truly transforming the organization to be agile requires a change of structure, which means changing the culture. Not an easy task, and not something to be undertaken lightly. It requires sufficient buy-in from the very top through every layer to the bottom.

Agile transformations often stall at the organizational level. Instead, we see pockets of conversion and pockets of resistance. It often takes changes in roles for the transformation to occur. However, just changing the way teams operate brings many benefits. While not really an agile transformation, a “switch” to agile project operation within a traditional organization can still be very beneficial.

So, while true agile transformations are rare, agile implementations are common and still worthwhile. The organization may never grow wings and fly as promised by consultants—but if it learns to wiggle more efficiently, avoid danger, and eat faster, that might be all it needs.

 

Digital Transformations  Digital

The goal: Digital transformations aim to convert and grow business in the self-serve digital domain. They do not have to involve websites, but many do. Rather than visiting offices or calling in for service, customers self-manage through apps and websites that greatly reduce labor costs and offer almost unlimited scaling opportunities.

The claimed benefits: Cost reduction and closer engagement are the main claimed benefits. They use websites and AI-powered chatbots to handle the majority of customer questions and interactions. This reduces the need to have as many people employed at physical locations and answering phone calls. Banks and insurance companies are undertaking digital transformations to offer services in convenient formats for customers (mobile phones) as well as reduce overheads.

Encouraging customers to manage their services via mobile apps also opens up options to ping, notify and promote upsell opportunities. It is cheaper and easier to push promotions and “exclusive member benefit offers” to people who install apps than compete for attention in traditional advertising channels. Apps also let companies gather additional marketing intelligence like location, contacts, spending habits, etc.—all additional fuel for promotions and potential sales.

The reality: Building compelling websites, apps and AI services is no small undertaking. Many organizations go through the significant expenditure to discover that only a portion of their customer base embraces the new options. Organizations then try carrot-and-stick paperless discounts or paper-based account fees to incentivize the desired behavior.

These new websites and app projects will never be finished or done. Since they now represent the organization's face and communications vehicle, expect ongoing investment in their upkeep and technology refresh cycles. When looking at the potential savings, do not underestimate the likelihood of initial build costs to spiral—and integration into existing back-end systems to be orders-of-magnitude more costly and time-consuming than anticipated.

However, it seems an inevitable trend. Using established content management systems and app frameworks can help rein in costs. Being at the forefront of technological capability is only paramount if your core business is selling technology services (Amazon, Apple, Google, Microsoft). For everyone else, fast-follower (or even majority-adopter) is probably fine. Digital transformations are real, already here and unlikely to be fading anytime soon.

 

Productization Transformations Product

The goal: This is the transition from using projects to build software systems to building and viewing software as long-term products. As organizations realize software represents a market differentiator, they recognize their systems will never be “done.” If they were to finish, it means they are no longer innovating, improving or competing.

So, they move from the start-stop world of software development through projects and instead adopt continuous development and drip-feed funding models. Historically, organizations staffed and funded projects through vendors and contractors using capital expenditure models. The switch to software as a long-lived product or service changes both staffing and budgeting. The increase in cloud-based hosting also raises the question of opex (operating expenditure) versus capex (capital expenditure) funding.

Organizations often reach out for help making these changes to development, staffing and funding models. This is the new and emerging world of productization or “continuous digital delivery.” It involves restructuring and forming long-lived product teams with everyone present to develop and maintain the software products over its entire lifespan.

The claimed benefits: By eliminating the handoffs between development teams and sustainment teams, more knowledge about the system, and how to extend it, is retained. Fewer handoffs in general is one of the biggest benefits of switching to products instead of projects. Handoffs are very wasteful—they contribute to the eight lean DOWNTIME wastes…

Defects
Overproduction
Waiting
Non-utilized talent
Transportation
Inventory excess
Motion waste
Extra processing

…all of which can occur when one group hands off work to another group.

By creating stable teams that are aligned with developing and sustaining long-term products, organizations can wean themselves off unpredictable vendor models. From a budgeting perspective, estimating the burn rates and capabilities of stable teams is much more reliable than estimating how long a new vendor-based team will take to complete some work.

Stability, continuous development and better knowledge retention are all compelling reasons to trade projects for products. The difficulties come in the transition and available support.

The reality: Switching from running traditional stop-and-start software projects to continuous product development is still a new idea. Usually, organizations have a suite of currently executing projects that still need to be delivered on schedule. Existing vendor contracts may make it difficult to switch to the onsite execution approach favored by continuous digital delivery.

Finance departments are typically set up to evaluate and approve requests for expenditures based on one- or multi-year ROI projections. In the continuous development world of productization, the spending never stops.

Instead of project-based funding, small teams create minimal viable products for evaluation. If they show promise, they get additional funding in more of a venture capital-style model. New metrics like customer market share and profit-to-funding ratios are used.

The benefits are real and don’t require a major upheaval to organizational culture or structures. However, experience is thin on the ground along with books and training courses. It’s like using what we today call agile approaches in the 1990s. There are early adopters, conference sessions and blog posts, but far to go before the idea even approaches the chasm (let alone crosses it).

 

Summary

“Transformation” is probably too grand a word for the degree of change most organizations achieve. However, as so many ideas compete for our limited attention spans, it would seem crazy to merely name a change initiative a “rollout” or “improvement” these days. People have become desensitised to reasonable names and seek revolution and excitement to generate the interest they need to participate.

We should not expect traditional organizations to truly match digital-first companies like Spotify. They were founded to disrupt existing businesses and came without the baggage of a traditional client base to support. (Also, they are led and staffed by people that share different values than most North American institutions.)

Their ideas may be great for other organizations to experiment with and adopt what works, but what makes them truly powerful is that the ideas were created internally and vetted through experiments. Copy the concept (internally generate new processes to solve local problems), but not Spotify’s actual procedures.

There is nothing wrong with buying the same kind of shoes as Michael Jordan wore (heck, if the placebo effect gets you exercising more, they were likely a good purchase). However, don’t leave your day job to sign up with a basketball team until you’re sure you are world class. Today’s transformations bring many benefits—as long as you take the “transformation” claim with a grain of salt.

 

[Note: I first wrote this article for ProjectManagement.com here]


Where Did All the Project Managers Go?

PuzzleSoftware is eating the world” claimed venture capitalist, Marc Andreessen in his 2011, New York Times article. Seven years on, the trend continues, and project managers are also on the menu. The next generation of project managers face new challenges but also new opportunities as organizations undergo a major transformation.

Software is becoming omnipresent, it is embedded and integral to all industries. Not just technology companies (like Google, Apple) but every sector is being disrupted by software including retail (Amazon), banking (PayPal, cryptocurrencies), transportation (Tesla, Uber), and travel (Airbnb).

As a project manager you may say “Great, just think of all those IT projects that will need project managers!” Well, that’s where things get interesting. First, today’s software teams don’t respond well to being “managed”, that’s old-school command-and-control thinking along with Gantt charts and calling people “resources”. Instead, they are led, empowered and supported by servant leaders. Next, the idea of a “project” with a defined endpoint is dissolving too.

As organizations realize their software systems provide the competitive advantage then stopping development equates to an end to innovation or competing. When organizations become more software-driven their systems are never “done”. As a result, organizations are switching from projects (that have a fixed end) to products - that continue to evolve. This movement popularized by the #NoProjects and Continuous Digital titles is growing exponentially.

 

 The Project Manager in a No Projects, No Managers Future

This double whammy of no more projects and no more managers likely creates heartburn for people with the job title “Project Manager”.  While this trend is clearly the future of work I believe there will always be a role for smart, cooperative people that can help with collaboration and development. 

 A quote that comes to mind is “The more things change, the more they stay the same.” by Jean-Baptiste Alphonse Karr. The next generation of project managers will have new titles like “Product Leads”, “Development Team Coordinators” and “Digital Transformation Leaders”. They will help organizations build development capabilities around long-term products.

 This new generation will still communicate with stakeholders about status and risks. They will still facilitate consensus gathering amongst experts. They will still try to diffuse conflict and find common ground during arguments. The goals (satisfied stakeholders and value delivery) will remain the same but the tools, titles and processes employed will be vastly different.

 

New Tools and Approaches

Heavy upfront planning efforts and the use of tools like critical path network diagrams and PERT charts are not so useful when the input data is very uncertain. Tools like work breakdown structures offer great insights into sub-system assemblies but they are slower and more difficult to reprioritize than modern backlogs and release roadmaps.

As rates of change increase so too does early lifecycle uncertainty and the competitive need to start work quickly. The days of carefully analyzing work products upfront are dwindling. Instead, organizations build prototypes based on what they know right now and then iterate towards the final product. In the intangible world of software, the cost of experimentation is less than that of detailed analysis.

Also, using a software product provides better feedback on its suitability and possible expansion than reviewing a document or diagram about it. IWKIWISI (I Will Know It When I See It) becomes the new mantra, replacing the “Plan the work, and work the plan” ideas of old.

As organizations adopt a continuous delivery model that is focussed on products not projects then funding models change also. Instead of yearly budget cycles to fund entire projects, smaller tranches of funds are released to create a Minimum Viable Product (MVP). Then, providing the product continues to return value, more funding is made available. A venture capital funding model lets product leaders focus on delivering a stream of high-value features that support continued investment.

Projects classically track metrics like on time/budget and Return On Investment (ROI). Products track customer satisfaction, market share, profit to funding ratios. They are similar concepts but a new vocabulary to learn.

 

Role Changes

Agile software development teams organize their own work, solve most of their own problems, and are empowered to experiment with new work strategies and approaches. They do not need (or want) to have work assigned to them, nor asked to report status. Instead, they make their work visible via kanban boards and new features.

They do however need people to remove impediments and chase up external dependencies. They also need investment in training, shielding from interruptions, plus regular encouragement and words of thanks to stay motivated. In short, all the servant leadership practices that good project managers did anyway still apply.

Project managers cannot be the center of work planning or task distribution. There is too much complexity to be anything but a bottleneck. Instead, we must trust development team members and product owners from the business as subject matter experts in their own domains.

Where these teams often need help is keeping the larger perspective on where it is we are trying to get to. When you are heads-down on solving a technical issue, it is easy to lose sight of the end goal. Having someone communicate the product vision reveals a beckoning summit towards which others can chart their own course.

In this way servant leadership and visionary leadership that predate modern project management are still valuable and needed. Yet the scientific project management that grew out of the industrialization of process is largely left behind.

 

The Future

In many industries, the classic role of projects and project managers will continue. I don’t see construction moving away from big upfront design and the reliance on project managers any time. In the software world though I think we are heading for substantial changes. Sure, some companies will continue as they always have with software project and project managers. However, most organizations will transition to long-term products with leaders and coordinators.

It is an exciting time for life-long learners willing to acquire new tools and approaches. There is no shortage of work for people who can collaborate with others and solve problems. The critical role of software will increase as organizations undertake digital transformation and adopt continuous digital strategies based on products vs projects. So, while the role “project manager” might be heading into the same category as “switchboard operators”, “human alarm clocks”, and “bowling alley pinsetters” the work and opportunities in this exciting field continue to grow.

[I first wrote this article for ProjectManagement.com here]


“When Will This Software Project Ever Be Done?”

NoProjects imageDoes this question sound familiar? If you get asked it regularly then you may be part of the mainstream transformation from software projects to products. It’s coming and it's going to turn many roles, certifications and in some cases entire companies on their heads.

 

The last couple of software projects I worked on were large, multi-year endeavors to build in-house systems that add competitive advantage for the sponsoring business group. It did not take multiple years to build the initial product, instead after delivery the business wanted more functionality, more integration, more automation.

The “When will you be done?” issue

The success and reliance on the new system bred further investment. The fact that business sponsors wanted to continue development was a good endorsement for the value being delivered. Yet there was a conflict at the steering committee level and PMO level. “When are you people going to be finished?” was the common question.

Answers like “never” or “when the business unit stops innovating and enters a decay phase” are generally not acceptable. Things are made worse by the teams being staffed, in large part, by expensive contractors. To the CFO or VP who does not use or see the benefits the system delivers these successful in-house products seem like make-work exercises or country-clubs for development teams that have become all too familiar with the business units they are embedded in.

This is not a problem, this is the future

However, we are not witnessing a problem, we are witnessing the future. Software is becoming more critical to business and projects are ending (or will never end) as we take more of a product vs project view of software.

Continue reading "“When Will This Software Project Ever Be Done?” " »