This is the latest in a series of articles on #noprojects; examining how organisations can deliver continuous change without project structures. If you haven’t already, you should read the first two in this series: first article and second article. This article will build upon the previously discussed concepts and methods of visualising and managing a continuous flow of change based on effort and value.
We will start this article by looking at the context of a change - an outcome. This will get practical with a detailed look at how we define outcomes, managing their interactions, and measuring our success. We’ll finish this article with a warning - the risk of shadow project emerging. That is, a work pattern that mimics a project structure in all but name.
What is an Outcome?
Fundamentally the goal of all projects is to create new organisational capability - be it technical or functional in nature. The question therefore becomes, can an organisation introduce new capability without a project driving it?
Simply put - yes. The key is to think of this capability as something of value - and outcome.
Whether at the level of team, division or organisation, the continuous flow of activities are focused on changing outcomes rather than outputs. An outcome is measured by its value to the organisation, whether direct & tangible or indirect & intangible. Outcomes are planned, slowly changing and define the common direction for the organisation.
However, outcomes can be complex, interdependent and occasionally conflicting. To effectively manage this at an organisation level we need to understand four things;
- the outcome profile,
- working principles,
- the relationship between outcomes,
- and unintended consequences
Outcome Profile
The profile of an outcome defines the context, intent and expectations for the team, division or organisation. While the characteristics of a profile will differ between organisations, at a minimum it should contain.
- Summary – a short description of the outcome.
- Baseline Measure – if the outcome is quantifiable, what is the current state?
- Owner – who (either an individual or team) is accountable for this outcome?
- Dependencies and Order (Ranking) – where does this outcome sits in relation to your other outcomes?
- Investment – what is your maximum available investment/budget to achieve this outcome?
- Current target - what are you trying to achieve? Try to avoid percentages (as they can be easily gamed) and remember that this is a current target. It will change over time. Depending on the context of the outcome, the current target may also have a timeframe or due date against it.
- Outcome test plan - how will you measure effectiveness of the activities against the outcome target?
What is NOT included in the profile is a plan. The team is expected to dynamically react and proact (if that’s not a word, it should be) to opportunities in the market or organisation by instituting continuous change.
Example Outcome Profiles
Working Principles
To be effective in the long term, outcomes need to be constrained. We can’t let divisions and teams do anything they want unchecked, while at the same time we can’t significantly restrict their ability to deliver. To that end we create a set of ranked principles - rules that apply to all activities regardless of outcome. It is expected that every organisation will create their own principles depending on what is important to them. Principles may constrain a team in areas of quality, communication, staff engagement, security, branding or any other common area.
Be aware that each principle brings with it an increase in cost and effort for every activity. For this reason, principles are given a ranking. You can use any prioritisation model, but I generally recommend MoSCoW.
- M - Must Have: non negotiable principles that every activity must comply to me in order to be considered done without exception.
For example: All activities must have associated automated unit tests written prior to development commencing (TDD) - S - Should Have: teams need to comply with these principles or justify their non-compliance.
For example: All authentication should link directly to the corporate Active Directory system - C - Could Have: optional principles that act as guidelines at the discretion of the team.
For example: OWASP security tests could be written for each activity and run as part of the regression test suite - W - Won’t Have: negative principles that teams should avoid.
Relationships between outcomes
There is also a natural granularity to outcomes at different levels of an organization. At an organisational level outcomes are generally broad and focused on revenue, staff and production.
Divisional outcomes are generally a natural decomposition of a single organisational outcome. The intent of this decomposition is to provide focus and ownership of the outcome within the organisation. Accountability will sit with a senior executive, eg. the CIO.
At a team level, outcomes are highly specific and should relate to the divisional outcomes. However, given the natural complexity in organisational structures, team level outcomes may also have secondary parent outcomes. Regardless of these relationships, accountability must sit with a single team leader or manager within a division.
For Example (Outcomes for a startup company):
Organisational Outcome: Sell the company for $X per share while guaranteeing jobs for 80% of existing staff.
Divisional Outcome: Increase revenue from subscriptions to $X per quarter
Team Outcome: Increase the conversion rate from free to paid account to 2%
Unintended consequences
The largest risk to this model of working are the unintended consequences caused by conflicting outcomes. Outcomes can conflict when there is poor communication and collaboration between divisions or teams, a lack of clarity when describing outcomes, conflicting priorities between distinct outcomes or the natural tension between growth/change and stability/status quo.
For technical teams, which is the context of this series of articles, these unintended consequences can be mitigated in 4 ways.
- A Publicly Available Activity Canvas: When the activity canvas of each team is visible to the entire organisation, teams validate that other activities will not negatively impact them. This requires teams to actively check the Activity Canvas of closely related teams. However, it is important to promote transparency and clarity of any changes that may cause a negative impact.
- Regularly re-form teams: By regularly moving people between Value Delivery Teams, not only are you sharing skills and expertise, you also break down any “us” vs. “them” behaviors that occur. In turn, this helps promote a collaboration of culture and identify any potentially conflicting changes before they occur.
- Automated testing, regression testing and rollback: Where a change relates directly to a technical environment any new or modified functions should go through three systems.
- An automated testing system - to validate that it works as expected,
- an automated regression testing system - to validate that it doesn't break another function, and
- an automated rollback system - to remove any change where there is an issue that wasn't identified in the previous two steps.
- Working Principles: Finally, the identification and development of each activity, needs to comply with the agreed working principles. This ensures that changes, which lead to short term gains, don’t lead to larger issues in the longer term.
Bringing it all together
Without binding a team to a specific output, an organisation that understands, and plans for, growth outcomes can fundamentally adapt to a changing market. Governance controls come in the form of common working principles and clearly defined, non-conflicting, outcomes. In this way, senior management can delegate the ‘how’ to their Value Delivery Teams, while retaining ownership of the ‘what’ and ‘why’.
Team Structuring
A quick note on team structuring. As discussed in previous articles, a Value Delivery Team isn’t built around functional silos (which may still exist in the rest of the organisation) but rather is formed with the appropriate mix of skills and roles to meet the outcome. Do not mistake this for a project team formed in a matrix organisation. Ideally, this is a permanent team (or division) reporting to a line manager who is accountable for the outcome.
The entire point of #noprojects is that this Value Delivery Team will create changes that work towards the target outcome.
Measuring Outcomes
Because each activity is small, the direct impact on the outcome may also be small or even unmeasurable. What we are interested in is the cumulative impact of all activities to the outcome. If the outcome is quantifiable the team should, at regular intervals, measure their progress against the baseline. The form of measurement will depend on the outcome and how it is quantified. Depending on the result, the team may also set a new target within the benefits profile, or change the outcome entirely. The organisation can use these measurements to make informed decisions about future investment and strategic directions.
A special case – A/B Testing and Continuous Measurement
In many cases outcomes can be mundane and predictable (e.g. “maintain operational stability & security”) with straightforward measures. However, for those activities with an unclear/uncertain impact on the outcome, we recommend the use of A/B testing and measurement when possible.
“As the name implies, two versions (A and B) are compared, which are identical except for one variation that might affect a user's behavior. Version A might be the currently used version (control), while Version B is modified in some respect (treatment). For instance, on an e-commerce website the purchase funnel is typically a good candidate for A/B testing, as even marginal improvements in drop-off rates can represent a significant gain in sales.” – Wikipedia
Measure the Value of an Actvity
Each Value Delivery Team that is accountable for all, or part, of an outcome will identify and undertake specific activities - read the previous article, “Focus on Value, Not Projects” (http://www.infoq.com/articles/<insert link here>), for more detail on this. The intent of each activity is to generate direct or indirect value in the context of the outcome. However there are 5 aspects that you need to consider.
1. Value degrades. This is actually the entire point of #noprojects; if you don’t keep up with change, you’ve already failed. The value generated by any activity, once implemented, will begin to degrade. The rate of degradation depends on the context but is, sadly, inevitable.
Value degrades over time
2. You don’t always work on the highest value activities first. Activities with dependences and due dates may precede high value activities.
Cost incurred vs value created over time
3. Local Maxima. If you find that your activities aren’t having the desired improvement to the outcome, sometimes you need to reduce the overall business value of the outcome in order to increase it further. For example, to remove functionality from a product in order to simplify further development. This may happen when you have reached a point of diminishing returns or the cost of change (or innovation) increases exponentially.
Value over time showing a local maxima
4. Activities fail. Not all activities will have a positive impact on the outcomes - some will be neutral or even negative. This is why activities are meant to be small, independent, and measured in aggregate. This independence also means that technically every activity can be rolled back.
5. The “So What” Factor. Before adding any activities to your activity matrix ask yourself “If I don't to this - so what?”
Outcomes are the lens through which activities are focused to create value for the organisation. Understanding this is half the battle to adopt #noprojects.
Shadow Projects
#noprojects is a cultural and behavioral change more than it is a process or technical change and nowhere is this more evident that the emergence of shadow projects. A Shadow Project is a pattern that emerges in #noprojects or continuous change environments that mimics a project structure in all but name.
To identify a shadow project in your organisation, it is important to understand the characteristics of a project. Of most relevance to us is the temporary, constrained and silo’d nature of projects.
Temporary
By definition, a project is a temporary structure to deliver a specific change or series of changes. This is fundamentally opposed to the principle of #noprojects which promotes a continuous change model — where there is value in the ongoing development of new capability. Shadow projects may emerge where teams are formed to produce a single output (which may be phrased as an outcome) and regularly diverted to different outputs/outcomes. This is compounded if the team is dispersed and potentially re-formed (or a different team created) to re-address that outcome at a later date.
Don’t mistake this for the natural end of a business experiment that doesn’t produce the expected results. Similarly don’t mistake this for the natural end-of-life of an outcome where the value vs. effort ratio goes negative.
Cost incurred vs value created over time
Constrained
Constraints are critically important in business, doubly so in #noprojects. However shadow projects can form where there are artificial constraints imposed on a team – usually in the form of fixed time, fixed cost or fixed scope. If your manager asks for a specific product or pre-defined set of activities, in a specific timeframe – that is a project.
Keep in mind that while individual activities can have due-date, there is fundamental difference between these constraints and a fixed scope or fixed goal.
Silo’d
A corollary to this is accountability, sponsorship and handover between functional silo’s. Because a project is a temporary structure, the line management of the project team usually differs from the management of the project. This can lead to multiple approvals, functional handovers and inefficient matrix structures.
A shadow project occurs when there are shadow, or parallel, approval processes between managers or functional areas. Whether structured as a Value Delivery Team or functionality hierarchy, #noprojects requires a single point of accountability for all delivered activities. In other words, the line manager of the team and the specific outcome “sponsor” should be the same person.
Final Thoughts
Fundamentally, without the associated adoption of a #noprojects mindset by both managers and staff, shadow projects will begin to emerge. At best these are the last-ditch attempts by the status-quo to remain relevant - at worst, they are an insidious attempt to subvert the intent & goals of your #noprojects initiative.
As long as you remain aware of these anti-patterns, you can identify and resolve them before they impact you.
About the Author
Evan Leybourn pioneered the field of Agile Business Management; applying the successful concepts and practices from the Lean and Agile movements to corporate management. He keeps busy as a business leader, consultant, non-executive director, conference speaker, internationally published author and father. Evan has a passion for building effective and productive organisations, filled with actively engaged and committed people. Only through this, can organisations flourish. His experience while holding senior leadership and board positions in both private industry and government has driven his work in business agility and he regularly speaks on these topics at local and international industry conferences. As well as writing "Directing the Agile Organisation", Evan currently works for IBM in Singapore to help them become a leading agile organisation. As always, all thoughts, ideas and comments are his own and do not represent his clients or employer.
