The first step is having the investments figured out.
Before I even start with my interpretation of Product Development Life Cycle (PDLC) management, we have to start with the money. Or more specifically, how to track the money.
It might sound strange for a Senior UX Designer to say that PDLC starts with tracking the money, but without a framework to track expenses, measuring ROI is an exercise in absurdity.
Nothing worse than being in an executive meeting evangelizing UX Design and then fail to explain how much and where the money was spent to further the strategic goals of the portfolio!
So if you're stepping into a Product Team and there's any ambiguity with money, STOP everything and rewind, to start with the money.
What is in this Blog?
How to Start with Money and Project Tracking
What was Yan Chow's part in this?
How to Start with Money and Project Tracking
The first rule with tracking money is to "make it easy" - and, coincidentally, this is also the first rule in Project Tracking, because the two are actually one in the same! The function of any Project Tracking platform, such as Jira, starts with BUDGET before its broken down to Container Teams, Releases, and Features.
However, nobody on the Development Teams themselves will ever think about "money" because their focus is on Product improvement and not bean counting!
In order to compensate for this lack of transparency, a Project Manager will impose a work agreement for the team to use esoteric naming conventions, labels and components, to classify the theme of their work. Unfortunately this will only add strain on the team and frustrate them over time.
So the question becomes, how can you track money and development work with ease to satisfy the reporting needs to the Executive Leadership Team (ELT) and create a passive and automated system for project tracking? It has to start with the Finance team.
Step ONE: The Finance team creates three types of Initiatives for Strategic Leadership to classify expenses to:
Development
Maintenance
Transformation
Step TWO: The Strategic Leadership team will forecast investment efforts with stakeholders on Product direction for the next three years.
Step THREE: Product Management will create the Sub-Initiatives for the Fiscal Year's Themes.
Step FOUR: The Product Owners will follow the strategy laid out by Management by writing Features for their Product release.
Step FIVE: The Product Development team will create the Stories that will complete the Feature.
By having the process start with Finance and utilizing the hierarchical format of the Project Tracking platform (Jira), the ability to track progress and money allocation solves itself.
So, what are these three Initiatives and why do you start by having them? By having Finance define these buckets, any Strategic Stakeholder or Investor can quickly discern the direction of a Product based on the type of investment theme.
Development Initiatives is work being put into the next major or minor release
Maintenance Initiatives is work being done to the current version (bug resolution, benchmark analysis, research, etc.)
Transformation Initiatives is miscellaneous work that doesn't fall into Development or Maintenance, but is related to transforming the Product in some capacity. Such as data migration, top tier research, or activity related to dismantling the product for sunset, retirement and/or archiving.
From the perspective of Finance, if a product is heavy in Development work, the ROI is expected to be LOW, because the money is being invested into research and development on a product that has not been released. However, if it is heavy in Maintenance, then this is a mature product that has been out to pasture collecting revenue for the company. Lastly, a product that's heavy in Transformational work could be positive or negative in ROI depending on the circumstances.
Example
(Step ONE) Finance has three categories for Initiatives created. (Step TWO) Strategic Leadership has a Globalization strategy for their products and writes an Initiative to update Products for French and Spanish support for the first Fiscal Year. The Theme is "Language updates" for Product Globalization.
(Step THREE) Product Managers are informed on Globalization and write Sub-Initiatives as child issues for their Product Owners to utilize for language updates.
(Step FOUR) Each Product Owner will write Language Update Features as part of their next minor release for the Program Increment. (Step FIVE) The embedded UX Designer will collaborate with the Translation Service team to prototype and conduct usability testing for the Product UI before handing it off to Development to implement.
In this Example project tracking will be easy due to the parent-child hierarchy from the Budget Initiative and Theme. As a result, comparing the estimated and actual cost for this is incredibly simple.
A Worst Case Scenario
The Finance team has a tenuous relationship with the Product and Technology portfolio and only care if basic accounting inputs are fulfilled. Product Managers are siloed from their own Dev teams and determine what actions are best based on Business Intelligence presentations, Market Research and interactions with Sales.
The Product Managers will write up a general roadmap for the year and propose it to Finance and ELT. Rudimentary questions will be asked, but generally the product is doing well on it's own and overhead expenses are carried over from last year.
Uncertainty in investment allocation will grow and decentralized leadership starts to become a disorganized. Engineering will become the strongest voice and advocates for technology upgrades to improve operational performance.
The UX team focuses on low key usability testing and not high key existentialist research that brings on innovation and industry disruption.
The death spiral continues and overall product confidence wains. Outside contractors are hired for their fresh perspective on why project tracking can't answer basic business questions under scrutiny. Money is being burned endlessly.
What was Yan Chow's Part in Project Tracking?
Project tracking requires a tether that all teams can pull themselves on andleads to a common milestone. My role in Design Operations was to create that "tether" and "milestone" system so that UX didn't appear to be operating in a vacuum. I also attended Project Status Report (PSR) meetings to represent the UX organization. I was never quite able to do things the way I wanted to, but I was still able to contribute a lot to the system.
I did a lot of training for the UX team and later I would extend this training to the Project Tracking Organization.
This is a simple example for a project tracking framework I wanted to enforce onto Development teams. I wanted every Dev team to utilize their Jira Components in the simplest format possible:
Research
Design
Development
Bug Tracking
To add nuance to the Component, Labels are added to the issue. This way, it becomes easier to classify activity without having to read into the title or description for every Story. Examples of Labels per Component:
Research
in-depth-user-interviews
accessibility-test
information-architecture
Design
prototyping
design-system-management-integration
component-update
The difference between Components and Labels are that "Components" are Admin controlled and "Labels" are based on the whim of the author. In that way, Labels can be more organic and dependent on the team to define. This might look like a mess at first, but as the team matures, a core set of labels will begin to emerge.
A good anti-pattern to watch out for are an excess of Labels attached to stories. It's an indication that a team is not mature and insecure on it's own project tracking efforts by overcompensating on labels. Such efforts become unsustainable and putter out within a Program Increment.
This minimal effort of utilizing Components and Labels is the simplest work agreement a Project Manager can impose on a Development team. Everything else will fall onto passive data values, such as the aforementioned Initiative Themes, Feature links, Release management, assignee, Story points, dependency, status and more.
Final Notes:
If I sound more like an Accountant or Project Analyst than UX Designer, it's probably because I've been on the receiving end of planning meeting more than I care to admit and can sympathize with leadership who need a resource that can breakdown and analyze the UX process for a product. UX Project Management has felt like the natural career direction based on my interest.
Comments