The second part of the How to Apply the ITM takes a different perspective than the ones previously introduced For Roles and Teams. Here we look at applying the ITM in a slightly broader perspective. Whereas the prior page looked to Agile coaching for Roles and Teams, the Model also offers Project coaching for specific objectives and broader interests. So, in addition to viewing how the Model can benefit individual Roles, it is also helpful to look at typical Objectives and Projects which could benefit by using the Model.
In any organization, a single weak area will impede overall success. Similarly, that may be the case on a specific initiative, even in an organization that is otherwise quite competent in that area. Whether due to resource constraints or lack of experience, a weak area is just as harmful as a weak team member. By not adequately contributing a critical portion, the overall initiative suffers, and may even fail. In contrast, get the objective of each area right, and the overall initiative will flourish.
Many people equate a Project with a Solution. In fact, they are different. For example, it is quite possible for a single Project to deal with more than one Solution. Conversely, it is also possible for a single Solution to be worked by more than one Project. Generally, even in cases where there appears to be a 1-to-1 relationship, take note that the Project will typically wind up long before the Solution is retired. The Model builds-in these distinctions, allowing for better execution of both Projects and Solutions.
For Specific Objectives
To begin, let's look at the specific objectives involved with establishing and executing a successful transformation initiative or enterprise software implementation. Traditional Project coaching may guide viewers to some subset of these objectives. However, for an Iterative Transformation approach, expect to revisit each objective multiple times over the course of a Solution's lifecycle. Therefore, it becomes more important to achieve a decent level of competency in each objective.
Project coaching for a non-iterative approach may highlight a failure of any one area need not doom the entire initiative. Alternatively, Project coaching for an iterative approach will highlight that failure in any one of these objectives will impede progress, raise costs, and delay value. All things which an iterative approach strives to avoid.
For Specific Projects
To begin with, let's make a quick clarification. Projects and Solutions often appear to be one and the same. However, they frequently are not. To illustrate, a Project typically ends much earlier than a new Solution. In the same fashion, it is not uncommon for a Project to be spun up to affect significant change to an existing Solution. Conversely, long after that Project concludes, the related Solution(s) will live on.
To put is another way, a given Project may affect multiple Solutions. Alternatively, a single Solution may support multiple Projects. For example, consider an enterprise Solution where one Project addresses Finance and another Supply Chain. Depending upon the core application, both may be working on the same Solution. In this case, each Project may progress on its own. However, each will need to take into consideration some aspects common to both,.
Project vs. Solution
Given the distinction between Projects and Solutions, let's consider a few ground rules that typical Project coaching may not cover. To begin with, many aspects people normally associate with Project Management, are, in fact, owned by the Solution.
To demonstrate, here are a few examples...
Timeframes
Within any Solution Phase, timeframes should be consistent. A Sprint takes 10 working days (typically), and a Release somewhere between 2 and 6 Sprints. A Project may not get to change those timeframes. Specifically, it should not be permitted to arbitrarily extend a Sprint, or to add / remove a Sprint from a Release in order to suit some (seemingly urgent) time constraint.
Management Tools
Similarly, a Project may not get to choose the Work or Test Management systems used. Imagine one Project working in Azure DevOps, and another working in Atlassian Jira, as both work on the same application. Can it be done? Sure. Is it a good idea? Absolutely not. In fact, where there is an enterprise standard - a best practice - even the Solution may not get to choose the management systems.
Roles & Processes
In addition, many Roles supporting a Project's initiatives may exist beyond the bounds of the Project's control. For example, the DevSecOps folks who support a Solution will establish many of the processes relating to Work Management and Change Control. In fact, multiple Projects working on the same Solution will have to share a single DevSecOps group. Each Project cannot have its own group.
Many other aspects associated with a traditional Project are determined by the Solution. Not the other way around. In other words, a Project must work with, not against, Solution standards.
That said, during a period in which there is a 1-to-1 relationship between a Project and a Solution, most of the ITM can be adopted by a Project. In fact, they are actually being adopted by the Solution. However, in this window they can be considered one and the same.
Moreover, during periods when there is not a 1-to-1 relationship, Projects can still apply the ITM to Roles and Teams as needed. Similarly, they can also apply specific objectives, as described above. However, the Model's Project coaching cautions against trying to fit everything into "the Project".
Project Management
The ITM is not a Project Management approach. In fact, Project Managers are encouraged to use their PMBOK, PRINCE2, or other standards. However, the Model's Project coaching insists some allowances be made. For example, most of the Model's management activities should occur outside of Project Management. To illustrate, Phase Planning, Release Planning, and Sprint Planning, are more closely aligned with the Solution than with the Project. Still, there is plenty of project work that occurs beyond the scope of the ITM. And the Model is designed to work with such efforts.
Many tasks, such as the following, occur in the Project realm, not the Solution realm:
- Risk, Issue, and Action Management
- Resource Management
- Change Requests
- Rollout and Change Management
- Project / Program Management
From a Project coaching perspective, Sprints and Releases, as well as the work done within each, should simply appear as time-boxes on a project plan. That is, Project Managers should not dictate what work is to be done. Rather, that is the responsibility of Solution Owners and Solution Managers, in collaboration with others such as Release Managers, Delivery Teams and Customers. However, Project Managers do facilitate such work, hence their responsibility for the other tasks.
General Knowledge
Above all, the ITM's Project coaching encourages Project & Program Managers, and PMOs in general, to focus upon the work for which they are best suited. It encourages PMs to be generalists, able to apply their knowledge and skills to work any Solution(s). On balance, it allows PMs to be effective without needing to deep knowledge of any particular Solution.
Specific Knowledge
Accordingly, the Model's Project coaching places expectations for specific knowledge - individual Solutions, applications, or technologies - into other resources who participate in, and otherwise support, a Project initiative. To better see how to use the ITM for a Project, see how it applies to one or more Solutions.
Next, look to For Single and Multiple Solutions to see how these objectives, and Projects, are applied to transformative implementations. Otherwise, select the consumer group below which best describes your interest.