We are blogging on all aspects of agile contracting, benefit management and project execution. We wish you welcome to participate in the discussions! Please register and log in by clicking on the padlock below.

Also download our book Agile Contracting and Execution which covers a lot of the areas we will discuss on this blog. You will find the book under Produkter - Agile Contracting and Execution.

The moderator will delete posts that are not within the intentions of this blog. Users who are misusing the blog will be blocked.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Team Blogs
    Team Blogs Find your favorite team blogs here.
  • Login
    Login Login form

Containers in an IT initiative – agile or not

Posted by on in Agile Contracting and Execution (ACE)


Helping clients with the value chain for IT initiatives, we often meet a variety of concepts and nomenclature concerning processes and artifacts. Consequently, we use a lot of time sorting out the understanding of the concepts. Where competence is low, we often observe a sense of “paper driven” activities forced by the need to follow ”the book”. In reality, these activities produce little or nothing with respect to obtain software of high quality.

There also are disagreements between the agile and non-agile communities concerning processes and artifacts. This article will point out that nevertheless, there are some overall similarities between the communities.

The kernel of our argument are what we call the “containers” of an IT initiative. Whether it is a project, program, or pure deliverables from a Kanban board, agile or not, they are the necessary elements for governance and for accomplishing the important thing: deliverables with high business value and quality, properly assimilated by the receiving organization and their end users.

Natural containers for an initiative includes software products, release plans, cost and benefit budgets, goals, risk analysis, and stakeholders: These containers should be elaborated and maintained continuously from start to end of the initiative. Whenever a project board needs a project brief, project initiation document, status, risk overview or whatever, it is just a snap shot from the containers at the given time.

Moreover, these containers might be considered as “competence blocks” in a training regime. Let us give an example:

The most important container in an IT initiative is the Product Breakdown Structure (PBS). In an agile project, the product backlog typically consists of epics and user stories expressed in an easy, rich and informal language, identifying requirements, acceptance criteria, goal achievement and stakeholders. PRINCE2’s product description is more formal, but interestingly it also contains skills required for both development and quality assurance of the product, which can be helpful when performing resource planning. A product item can in turn itself be considered as a container for all necessary information concerning specification, design, development, testing, training and transition, next to contain the expected cost and benefit (and how to harvest the benefit in the organization) and progress status of the item itself[1].

The competence blocks[2] associated with products could be all the practice and theory involved with product specification, budgeting, design, product acceptance criteria’s, etc. The work processes are about doing the stuff needed, like specifying with users, estimating cost and benefits, defining acceptance criteria, etc. This is illustrated in Figure 1.


Figure1: Example illustrate the relationship between a container (Software products), its accompanying competence blocks (Competence) and work processes

From this perspective, one easily could build a modular and transparent overview of the elements needed in the life cycle of an IT-initiative, activities needed to build or maintain the containers, and the competencies necessary to perform the work.

[As an interesting side effect, direct linking containers to a person’s skill overview, might not only ease the resource allocation process when searching for the right available people (a competence “equals” a work process), but also give explicit aid to competence planning, recruiting or hiring of resources.

It might also be taken further to the corporate strategic level by viewing the market to be activities one does or wants to do there (“Today, we are helping our clients with building business cases”, “Tomorrow, we want to help our clients building apps for the future”). One can easily confer the corporate skills database (which at this point should be populated with competence/work process skills) for making a gap analysis between present and future skills needed, and further make a strategy for how to meet this.]

More examples of containers

Let us return to exemplify some more containers.

An IT initiative is a strategic initiative to meet some business objectives. How the initiative has emerged obviously differ, but it usually ends up as an idea to be further investigated, that meet some needs. By mentioning needs it means that we also have an idea about stakeholders.

Elaborating the idea further by enriching needs and requirements, stakeholder analysis and business objectives, we also draft the software products for the initiative. The products should explicitly be linked to the impact they will have on end user behavior and business processes, and ultimately the business objectives as illustrated in figure 2. At this stage, it would be natural to investigate different conceptual solutions for the initiative, based on how they meet the objectives, in addition to expected costs and benefits. A chosen concept together with the above elements are roughly the content of the business case. At this stage, one would also have some rough idea about cost and benefits associated to the products, an overall plan for delivering them as well as a risk analysis.



Figure2: Value Breakdown Structure (VBS) makes it possible to identify the key drivers for the initiative, in this example by assuming distribution of benefits and cost on the product items

Working out the ideas in an early stage will result in key containers, to be continuously elaborated during the life cycle of the IT initiative. You have established some containers that will be improved and maintained as long as there are resources to support it, conceptual simple and easy to communicate.  

When further planning and executing the initiative, one enriches and maintains the containers with respect to the development model one chooses (agile or not). The main differences here is the pace of releases (deliveries) and the (total) completeness of specification. In agile one would have frequent releases that are specified closer just before development are to be performed, whether non-agile usually prefer to have fewer (bigger) releases with most elements specified up front. These main differences may lead to different “principles” and practices regarding interaction with stakeholders, communication, specification, test, risk management, prioritizing, training, and transition. The main message, however, is that system development (agile or not) requires basic understanding and skills on elements and processes, ranging from developing the business case, specification of requirements and solutions, planning, estimation, testing, developing, training, transition, user interaction, architecture, to management and communication, procurement and contracts,  and stakeholder management. Elements and processes can be contextualized in chunks – or containers, possibly closing down the gap between the different communities. As the example with product breakdown structure shows: Same content, but (slightly) different wrapping!


[1]   Agile Contracting and Execution (ACE), PROMIS AS 2014, ISBN: 978-82-93381-03-7, www.promis.no  


[1] A product’s status might simple be 0% (not started), 10% (requirement analysis done), 30% (solution description done), 85% (development done) and 100% (in production).

[2] One can add the parameters “The level of competence I have” and “The level of competence I wish to have” on the container, which gives rich possibilities for knowledge management in the given enterprise.           

Continue reading
Hits: 416

ACE reinforces the concept of Value Breakdown Structure!

Posted by on in Agile Contracting and Execution (ACE)

PRINCE2® replaced the traditional Work Breakdown Structure with the Product Breakdown Structure. This may seem like a modest change, but we think of this as a major and necessary shift in project focus: Rather than focusing on activities and a breakdown structure with simple tasks as its leaf nodes, we shift our focus towards products and deliveries as leaf nodes. This we regard as a major improvement in project theory and practice, aiming to reduce and ultimately remove sub-optimization.

If Project Plans, budgets, management, and reporting all concentrate on the main thing - running software of high quality - there will be less room to cultivate ‘silos’ in the project organization. To exemplify such silos, we mention the “perfect” Project Management Office producing beautiful reports (and spending up to 4% of the Project Budget on project control), the Product Managers and Architects grooming their backlog items way beyond necessary standards, or the Test Managers producing waterproof test plans and procedures (and blaming the other departments for all sorts of delays). Such silos may arise from exaggerated focus on project artifacts such as reports, test plans, backlog items or architecture documents. Focus should be on software quality, not the quality of a given artefact.

The most significant symptom of sub-optimization is ‘over-reporting’, as when management on different levels requires written reports, be it on mail or PowerPoint, weekly or even more frequently. All communication in agile software development initiatives should employ face-to-face talks, the only exception being routine reports to the Project Board at the end of each Iteration. The volume and quality of the Stories delivered in each Iteration speak their own language, and this is the key to reporting and progress monitoring. All resources and activities should contribute to secure these most central deliveries from the initiative.

For agile software development initiatives, ACE recommends a Product Breakdown Structure as illustrated below.

In the first level, we have the Business Objectives, and first and foremost the Effect goals (expected outcomes, or impacts). These are quantified goals, describing what the receiving organization wants to obtain by implementing the deliveries from the software development initiative. An example could be ‘The case handling efforts should be reduced by 30%’. If done correctly, these Effect goals should be tightly connected to the Business Case and optimally the Benefits Realization Plan, in such a way that each Effect goal is delegated its own responsibility for quantified benefits.

In the second level, we have Epics. An Epic is a high level user story, describing a set of software features that combine to fulfill a certain goal for a certain stakeholder. An example could be ‘As a case handler, I want the case handling system to be fully integrated with the archive, so that I do not have to work in two different systems simultaneously’. This level of Epics is a strong concept in Project and Release planning, especially if we utilize Story Points and Benefit Points to distribute cost and benefit parameters from this level and further down the hierarchy in the Product Breakdown Structure.

In this way, ACE has cultivated the concept of Product Breakdown Structure, by introducing both cost and benefit values on the nodes in the structure. If the cost and benefit values are inherited from, and continuously aligned with, the business case, we arrive at a third generation of Breakdown Structures. The concept of Value Breakdown Structure was introduced by Stephen Devaux in 1999*, and we consider the approach presented in ACE as a reinforcement of this concept.

We may visualize the 3 different perspectives on software development initiatives in the following way: 


The relations between Effect goals and Epics could be many-to-many, in that a certain Epic could partly or fully satisfy one or more Effect goals. The normal situation in software development initiatives is that you have a few Effect goals, but a number of Epics at the next level.

The third level in the Value Breakdown Structure is the Story level. The Story is the unit that is handed over for Construction in the system development value chain. Optimally, it should be small (50 – 150 construction hours to meet ‘Definition of Done’).

The relationship between Epics and Stories is one-to-many, as in a tree structure. Together the Epics and Stories constitute the Product Backlog. For the Product Manager and Project Management it is sufficient to focus on these levels. The Development teams will take care of the detailed structure beneath the level of Stories. This happens during Iteration Planning, where selected Stories are broken further down into Iteration tasks.

* Stephen Devaux: "Total Project Control: A Practitioners Guide to Managing Projects as Investments". CRC Press 2014


Continue reading
Hits: 7442