Have you ever applied weights to project dimensions?
A business need comes up, and it looks best served by an IT solution. Here’s a consideration for a CIO on a project charter: the weighting of typical project dimensions.
Why? The dimension weighting will dictate the design and architectural decision priorities needed to implement an acceptable solution. As the CIO, try applying weights to these dimensions to direct the right design and architecture decisions. Try it below: the starting weights are my example, which add up to 100, and the charter section underneath rewrites itself to match whatever you choose.
| Dimension | Weight |
|---|---|
| A. Defined and implemented KPIs | 15 |
| B. Stay on our current technology stack | 0 |
| C. Limited deviation from budget and resourcing | 10 |
| D. Supportable by existing staff with their existing skills | 15 |
| E. Limited to the support staff defined in the project | 10 |
| F. Self-serve for stakeholders and intended users | 20 |
| G. Scale and morph easily to handle growth and change | 10 |
| H. Each processing run is time-bound and fits defined limits | 20 |
A. This project should have defined and implemented KPIs
The goals or aims of the organization make up the seedbed for a project’s KPIs. Gaining benefits from KPIs is a higher-order task, correlated to an IT shop’s maturity or openness. There are costs to building this in up front to gain the benefits downstream.
B. This project should stay on our current technology stack
The best tools, frameworks, platforms and libraries for the solution may differ from the set your support developers are fluent in. What does it cost to have them available to support the application? What are the benefits and risks of using the new stack?
C. This project should have limited deviation from its budget and resourcing
If these are hard and fast, going down experimental roads can’t happen. The risks of an updated tech stack should be off the table.
D. Once delivered, this project must be supportable by our existing staff with their existing skills
To meet this, you need to ask: How easily can other developers maintain this app? Does the authoring developer need to be there to support it? Can good documentation cover the gap if the author is no longer available?
E. Once delivered, this project is limited to the support staff defined in the project
If, say, two FTEs are required, additional staffing above that won’t be available. To meet this, you need to ask: How much time does it take to support this app? What staff count and skill set are required? What’s the average time to resolve an incident, and how many incidents come in over a period of time? If your current support staff have free cycles, this is less of a risk.
F. This project must be self-serve for its stakeholders and intended users
This expectation allows support costs to be reduced. If it isn’t self-serve, do you have the staff with the skills to support its use?
G. This project will need to scale and morph easily to handle growth and change
The architecture will need features to scale up processing, data growth and so on. Third-party platforms that provide some of this have costs to consider.
H. Each processing run is time-bound and must fit within defined limits
Here is where your app’s design needs to consider its performance capabilities, so that it fits within the defined limits.
So, does performance rule?
In this example, performance (H) and self-serve (F) carry the most weight, so they get first call on design decisions, while staying on the current stack (B) doesn’t matter at all. Your weights will differ by project, and that’s the point: decide them in the charter, before the design starts, and every architecture decision after that has a tiebreaker.
Weigh your project
Total: 100
Project charter
