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.
The competence blocks 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!
 Agile Contracting and Execution (ACE), PROMIS AS 2014, ISBN: 978-82-93381-03-7, www.promis.no
 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).
 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.