Project to Product Transformation: How to Get Started

This post is an excerpt from the Moving from Project to Product white paper by Ross Clanton, Carmen DeArdo, Mik Kersten, Alan Nance, Karen Person, and Jason Zubric. You can read the full white paper here.

In our previous blog we clarified what a product-based software delivery model is.

In this post we provide some recommendations on how to get started on your project to product transformation, but it should be noted that this is not something where “one size fits all.” Every organization has its own culture and will take its own path to success. Consider the following as advice on things that have worked at other enterprises rather than an exact blueprint for your organization.

1. Priming the Pump

Before actually talking about moving to a product-based structure, there’s some work that can be done to increase your chances of success. Consider moving from a model where people are moved from application areas to form project teams to a model that moves the project work to these established teams. 

This mitigates the issue of having to constantly form and reform teams around projects that are temporal in nature and don’t provide a sustainable model of getting work done.

So while there may still be portfolios of projects and project managers, the heavy lifting will be done by the established Agile teams that are impacted by the project. If a given feature of a project has stories that have to be completed (e.g., Story 1 by Team A and Story 2 by Team B), this work will flow into the backlog of those teams who will pull that work in based on priority.

Ultimately, you would look for this priority to be determined by the product owner. However, at this stage in your journey, you may look to this role being filled by internal IT personnel. It’s important to note in this model that control for what work gets prioritized and delivered shifts from the project managers to the product owner (and broader Agile team).

2. Start Small

As with other Agile initiatives, it pays to start small and build momentum. Changing the culture of a large organization is not something that can be forced, even if there is top-down support. But many times, these types of initiatives that don’t have full support in the beginning can be expanded, as is described in the 2017 DevOps Enterprise Forum paper Expanding Pockets of Greatness.

Finding one area of the enterprise that is open to working in the product model is a great way to start. This can be used to demonstrate that the product-based model is possible to accomplish, and this area’s success can be used to counter resistance. It changes the conversation from “This can’t be done here” to “This is how it can be done here.”

The following are some criteria that can be leveraged to maximize the chance of success:

• Have a supportive IT leader. There needs to be someone at an executive or leadership level that is willing to be a champion for the team. This is a journey. Things will not always go smoothly, and the team needs cover from a strong leader who has their back.
• Have a supportive business leader. While many Agile or Lean efforts have traditionally been driven from inside IT only, this transformation can’t be done without a willing business champion. This will require changes in how the business and IT work together. The business and IT leaders involved have to work as one team and be willing to address risks associated with this change while providing servant leadership by supporting the teams, listening to their needs, clearing impediments, and modeling the way for the overall change in behavior needed.
• Start small. Within the portfolio of that area, identify a product (or small set of products) for which an MVP can be defined and for which a single two-pizza team can support.
• Assign a product owner. There needs to be an assigned product owner from the business who can sit with the team and manage the funding and prioritization of the work to flow it into their backlog. This requires a significant commitment from the business, as product ownership requires a much deeper and more ongoing business engagement than traditional project management models.
• Reduce lead time by providing more autonomy. In order to reduce lead time (improve flow), product teams need more autonomy to plan and deploy business capabilities across technology domains (e.g., web, mobile) and across impacted applications (perhaps using an innersourcing model). Assuming the product team has the technical ability and expertise, they can make the changes to the application and issue a pull (or merge) request to that application owner. That owner can then review, validate, and accept the change, including it into their application, which can then go into their next application release.

Sign up for the IT Revolution Newsletter for more articles like this.

3. Label This an Experiment

Even with IT and business leader support, this should be viewed by the enterprise as an experiment. It’s an attempt to learn what works, what doesn’t, and how the organization can be improved.

In order to run an experiment, there must be criteria to determine if it is, in fact, successful or not. Examples of metrics to track are things like flow metrics (e.g., flow of business value stories). The goal of moving to the product model is to increase flow and reduce lead time while maintaining or improving quality and cost. In reality, there is data that demonstrates quality and cost will be improved, but at this point, don’t set the bar too high. Simply to “do no harm” will suffice if flow is improved.

There is also an aspect of this relating to W. Edward Deming’s concept of “quality circles.” The team itself understands best what is inhibiting their flow and how to improve it. The team should use retrospectives to ask themselves why certain stories had shorter lead times than others and what improvements can be made. If there is a need for a change that extends beyond this team, it can be escalated up through leadership to address the application of Deming’s concept of “systems thinking.”

4. Make the Work Necessary to Adopt This Model Visible

After establishing the initial experiments, there needs to be a focus on continuous improvement to continue adapting this model. Per Dominica DeGrandis’s book Making Work Visible, make this continuous improvement work visible. Leveraging kanban boards and placing your work in public viewing areas, like on TV monitors or walls near where your teams sit, is a great example of this. It will take team bandwidth to adapt this model, so be transparent about it. Track blockers just like the team would for any other business deliverable and escalate those blockers to their leaders to address.

5. Have Show and Tells and Invite Executives

One powerful way to move culture is to have retrospectives and show and tells (at least once a month) that focus on the adoption of this model. Having executives share the energy and the excitement of the team as well as the successes and areas where they need help can be a very powerful way to impact the executive mindset, which is necessary to expand the product model to other areas. Giving executives a sense of ownership over supporting the team in making this work will pave the way for future success.

6. Celebrate Small Wins

Many organizations are not good at celebrating and publicizing wins. We talk a lot about what is going wrong, but we don’t talk as much about what is working well. Stories are powerful! People remember stories being told by the teams doing the work. When other teams see their peers succeeding, it is powerful proof that this is not just a theory but a possibility right here, right now. Having the business leader talk about how this model is helping them succeed in the marketplace is extremely effective.

Having teams tell their stories and sharing credit for success is an important component to build the critical mass necessary for broader adoption.

7. Have the Patience to Persevere

The journey ahead will seem daunting. It is necessary to reflect on how far you’ve come and not just on how far there is to go. Reach out beyond your company to the broader DevOps community and to others who are on the same journey or who have already successfully demonstrated success in the product model. At times it may feel like a scene out of Dickens, being the best and worst of times. Have patience, persevere, keep the faith, and don’t be afraid to ask for help. It won’t be easy, but it will be satisfying to see the progress that you will make.

You can download the full Moving from Project to Product white paper for free here.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•