Introduction to the Ferroque Services Roadmap Pyramid

Purpose

This blog’s purpose is to inform the audience about Ferroque Systems’ structured approach to guiding customers in translating high-level corporate objectives into implemented IT solutions.

Target Audience

This blog is targeted at executive, upper, and middle management who are looking for guidance on how to drive tangible action throughout various organizational levels to achieve overall corporate IT objectives.

Introduction

In our popular four-part blog series on Managed Services In The Modern Economy, we reviewed typical elements of a managed services provider (MSP), MSP offerings, and key attributes distinguishing good providers from their peers.  Among other things, reviewed the Optimization and Transformation MSP engagement types (included in Ferroque MSP Premium) and highlighted the Ferroque Roadmap Pyramid, which is a model that Ferroque uses as a framework for engaging strategically with our Managed Services (MSP) and Professional Services (PS) customers.

In this blog, we will describe the Ferroque Roadmap Pyramid by walking through each level to detail the activities that occur, necessary participants and inputs, expected outcomes, and consumers. This will provide an in-depth look at how Ferroque applies our in-house methodology to follow a structured approach to drive deliberate outcomes (for example, translating high-level corporate objectives into tangible solutions).

Pyramid Overview

Within Ferroque Systems, we use the Roadmap Pyramid as a framework for strategically engaging our Managed Services (MSP) and Professional Services customers.  We have found it particularly useful in helping to drive collaborative efforts to assist customers in defining solutions to achieve their corporate objectives.  This is typically a challenge for most companies since corporate objectives are defined at a high level and require each department within the company to define, plan, and implement department-level objectives that, collectively across all departments, will enable the company to achieve its corporate objectives.  In these situations, the Roadmap Pyramid provides a common framework that helps anchor the conversations and facilitates getting all relevant persons to work together across multiple separate but related initiatives.

The Roadmap Pyramid consists of eight levels and outlines a model of working in incremental steps wherein the outputs of one level are used as the inputs of the next-lower level to methodically progress from corporate objectives to implemented solutions, as illustrated below.

The key themes of each level are summarized as follows, and we go into greater detail of each next.

• Pyramid Overview:
  • The Roadmap Pyramid drives the definition and implementation of solutions to achieve corporate objectives.
  • Consists of eight incremental levels, with each level’s outputs serving as inputs for the next level.
• Levels of the Roadmap Pyramid:
  • Level 1 – Corporate Objectives: Defined by executive leadership to provide strategic direction.
  • Level 2 – Department Goals: Each department defines its goals to collectively accomplish corporate objectives, resulting in detailed roadmaps.
  • Level 3 – Requirements and Needs: Defines functional requirements and use cases for achieving department goals.
  • Level 4 – Proposed Solutions: Brainstorming and proposing solutions to meet roadmap goals, emphasizing the usability of the solution.
  • Level 5 – Project Charter: Defines project scope, objectives, and key elements for implementation.
  • Level 6 – Defined Scope: Finalizes the specific scope and objectives based upon the Project Charter.
  • Level 7 – Work Packages: Creates a project schedule containing work breakdown structures comprised of work packages.
  • Level 8 – Tasks: Details specific tasks needed to complete work packages and the overall project (to accomplish corporate objectives).

Level 1 – Corporate Objectives

This level consists of defining and communicating corporate objectives, which is usually performed by executive (C-level) leadership.  Typically, corporate objectives are defined annually to provide strategic direction for the company.  Corporate objectives are defined at a macro level and are typically outcome-based (e.g. increase annual subscription license sales by 10%) as opposed to task-based (e.g. achieve 100% completion of sales account plans), and are intended to compel departments within the company to define their own department goals that collectively across all departments will help the company achieve its corporate objectives.

Level 2 – Department Goals

This level consists of each department defining and communicating its own departmental goals, which is usually performed by department leadership (VP, Director) who will use the corporate objectives as inputs to define their own set of department goals that collectively across all departments will help the company achieve its corporate objectives.  Department goals may be defined at a macro level or may be more granular and should roll up to help achieve one or more of the corporate objectives.

As an outcome of this level, one (or more) roadmap should be defined for each department and is typically produced by department leadership, with assistance from Ferroque if desired.  In our experience, we have seen many types of roadmaps and have observed the most useful roadmaps to contain the following (at minimum):

• Stated objectives in the form of outcomes that clarify the definition of success.
• Each objective is itemized into milestones (a series of sub-tasks required to accomplish an objective).
• Milestones are plotted on an estimated timeframe, often defined in increments of calendar quarters.
• Any key inputs/dependencies and when such inputs will be available.

The most common roadmap layout depicts calendar quarters as columns and items such as core teams responsible for implementation, capabilities and supporting technologies, prerequisites, etc., depicted as rows (aka “swim lanes”).  The roadmap should be described at a high level and be intuitive to understand.  It may also contain a legend (e.g. if it is colour-coded) and an accompanying memo if further details are necessary to facilitate clear understanding.  Roadmaps are typically created in Microsoft Visio (on occasion, we have also seen PowerPoint and Word used).

In this context, each department defines one or more roadmaps depending upon the number and complexity of goals for the department.  Note that this may be an iterative process as roadmaps are reviewed and refined until they achieve an appropriate level of detail.  Departments may move forward from this level individually, or progress may wait until all departments have completed their roadmaps (typically, this decision is made based upon the combination of cross-department goals that collectively sum to implement a given corporate objective, wherein those roadmaps collectively move forward in unison to drive a coordinated effort to achieve the overall solution).

Level 3 – Requirements and Needs

This level consists of reviewing the department roadmaps (from Level 2) to determine the necessary requirements. Initially, this is focused on functional requirements (rather than technical requirements) and is often made easier by focusing on the requirements needed to accomplish each milestone. This also helps determine the timing of when certain requirements will become necessary to keep making progress.

At this point, be mindful not to present solutions in the form of requirements; i.e. to the extent possible, the requirements should not state specific IT systems, as that would presume the specific IT system(s) will comprise part of the solution (which is the purpose of the ensuing level in the pyramid).

Functional use cases should also be included with requirements to describe how the solution should be able to be used by end-users (e.g. which users/groups, user locations and time zones, availability, etc.).  Any known technical requirements should also be determined based on functional requirements and use cases; e.g. if remote access by third-party users (B2B) is required, then that may trigger a technical requirement for multi-factor authentication (MFA).  Additional technical requirements will be determined later in the process (as part of determining solution options).

For each roadmap, outcomes should include the list of functional and technical requirements and use cases for each milestone, and the identification of any requirements or use cases that may be considered prerequisites to a downstream milestone(s).  This activity should be conducted with the same department leaders who participated in defining department roadmaps to ensure accuracy when translating department goals/milestones into tangible requirements and use cases (i.e. avoid anything being lost in translation), with assistance from Ferroque if desired.

Level 4 – Proposed Solutions

This level consists of reviewing the department roadmaps with requirements and use cases (from Level 3) to determine solution options to accomplish the roadmap goals/milestones. Typically, this is accomplished via group brainstorming amongst the BRM (business relationship manager) and relevant IT lead(s) for the IT area(s) expected to be in the eventual solution’s scope.

At this point, be mindful to propose solutions from the end-user perspective (rather than from the IT perspective) to facilitate better usability.  Depending upon the size and complexity of the roadmap, this step may start with a wireframe (skeleton) of the proposed solution to describe how the solution would work.  In our experience, sometimes a simple PowerPoint presentation is sufficient to depict the workflow (e.g., each slide represents a specific step in the process, and slides may contain clickable words and/or pictures that link to other slides to simulate workflow navigation).  The goal here is to clearly demonstrate how the proposed process/workflow fulfills stated requirements and use cases so the BRM and/or department leaders can get a feel for how the proposed solution will take shape, overall usability, etc. (similar to a concept car wherein the car obviously does not work but is sufficient for the audience to review the shape/form, size, internal layout, etc. to see if and how closely it does or does not meet expectations).

Also note that initially, in many cases, it is good to avoid trying to state the specific technologies that will comprise the final solution, as sometimes this can inadvertently constrain the brainstorming process.  Ideally, specific technologies should not be stated until there is agreement with the BRM and/or department leaders on the workflow (usage) for the proposed solution.  Proceeding in this fashion and including functional representation helps ensure the eventual solution will fulfill requirements and usage as originally articulated by department leadership, thus avoiding the all-too-common outcome of implementing a solution that significantly misses expectations. Paragon Innovations’ classic “tree swing” diagram illustrates this challenge succinctly.

Once the proposed workflow has been agreed upon, the next step is to propose relevant technologies to accomplish the proposed process/workflow.  Depending upon roadmap size and complexity, this process may be fairly simple or may be rather complex.  Traditionally this began with understanding the technologies a company already had in-house since that often presented inherent technology constraints; however, the current prevalence of SaaS-based solutions and public cloud significantly expands potential options.  Each proposed solution should describe how the relevant technologies will be integrated into a solution that implements the agreed-upon process/workflow while also adhering to established corporate technology standards, security posture, and operational practices.  Any key assumptions, constraints, and risks associated with each proposed solution should be included.

The goal of this step is to describe all proposed solutions and then prioritize for feasibility, fitness for purpose, time to deployment, and cost.  It has been our experience that, for very complex solutions, a pairwise comparison can help determine relative priority, wherein the degree to which each proposed solution fulfills stated criteria (e.g. individual requirements, use cases, etc.) is scored (e.g. scale of 1-5) and then ranked according to the relative importance (weight) of each criterion.  Part 2 of our blog on the Tao of Technology Architecture contains detailed guidance on how to go about this and related activities to help form a solution.

As an outcome of this level, a “winning” proposed solution should be identified and outlined in a solution roadmap (as described in Level 2 above) to articulate the solution’s milestones, estimated timeframes per milestone, and any prerequisites.  The roadmap should be reviewed with the relevant department and IT leaders to ensure collective agreement.

Level 5 – Project Charter

At this point, we are typically beginning to operate at the project level.  This level consists of using the solution roadmap(s) as a key input to define a project to implement the proposed solution.  Typically, project definition is in the form of a Project Charter that defines key elements such as project scope and objectives, estimated level of effort, outputs and deliverables, key assumptions, risks, and constraints, core prerequisites, project stakeholders, and estimated costs.

If the project will be conducted in-house then relevant in-house processes will be followed.  If all or part of the project will be conducted by a third party then the Project Charter will be used to engage such third-party firms so they may provide a proposal (e.g. Statement of Work/SOW).  Very complex projects may warrant the company to use the Project Charter to draft and broadcast a Request for Proposal (RFP) to solicit bids (proposal responses) from third-party firms.  Typically, the decision of whether to conduct the project in-house or via a third party (partially or fully) depends upon the availability of in-house expertise with the necessary technologies, personnel capacity, desired timeframe/speed of implementation, and available budget/funds.

This process is typically driven and conducted by the organization’s Project Management Office/PMO (if the company contains a PMO), and Ferroque can assist if desired.  For Ferroque MSP customers, such efforts are typically conducted via a combination of our MSP and our Professional Services (PS) teams, wherein the PS team manages and conducts the project and works with the MSP team to conduct deployments into the production environment (in alignment with change management).

Level 6 – Defined Scope

This level consists of finalizing the specific scope and objectives of the project to be performed based on the initial scope definition in the Project Charter.  For small and medium-sized projects, this may already have been performed when defining the Project Charter (Level 5 above).  Larger and/or more complex projects typically consist of multiple workstreams that are each often conducted essentially as micro-projects, each with its own scope, deliverables, etc.  In this context, it is imperative for the scope of each workstream to be appropriately defined so the collective outputs across all workstreams will come together to fulfill expected project outcomes.

As may be inferred above, at first glance, this level may seem somewhat redundant; however, in practice, it is often the case that there are distinctions between the initial Project Charter and the final project scope, objectives, deliverables, etc. that are ultimately agreed upon (e.g. due to insufficient resources and/or budget).  For this reason, the scope must often be finalized (fine-tuned) from the scope as defined in the original Project Charter.

The outcome of this level is a confirmed final project scope definition document (and/or SOW) that has been agreed upon by all customer stakeholders (and third-party, if a third-party firm is engaged), and is typically authored by the Project Manager (PM), who may be provided by the company’s PMO or by a third-party firm.  For Ferroque MSP customers, the Ferroque Service Delivery Manager/SDM typically participates in helping to finalize a project scope that affects any technologies in the managed environment (i.e. the environment for which Ferroque MSP is responsible for managing/supporting).

Level 7 – Work Packages

This level consists of using project scope and objectives, deliverables, etc. to create a project schedule (commonly referred to as a project workplan), which consists of work breakdown structures/WBS (a collection of work packages organized to plan and conduct all efforts necessary to complete a project), estimated duration, and activity owners to drive project efforts.  Typically, the project schedule is created and managed by the PM.

Ferroque MSP SDMs are certified in ITIL and PMP, thus in alignment with PMP concepts, within the project schedule we typically define several work packages (series of activities organized to create a deliverable) to organize the overall effort into manageable segments.  This model allows us to gradually define more granular work efforts that facilitate a modular project delivery (to accomplish work in parallel when possible, vs. entirely sequential) and makes it easier to identify activities on the critical path, which aids more accurate time estimates (and for very complex projects, more easily lends itself to use earned value management/EVM techniques).

In a traditional project schedule created in MS Project, a work package can essentially be considered as the most granular level of rollup tasks (i.e. a rollup task that does not contain any sub-rollup tasks).  In this context, the primary outcome of this level is a project schedule that contains all work packages.

Level 8 – Tasks

This level consists of decomposing work packages (defined in the project schedule) into the specific project tasks (activities) that must be performed to complete each work package and, ultimately, to complete the project.  Such tasks are the smallest unit of granularity in a project schedule, and within the schedule (i.e. within each work package), the tasks are organized in the sequence in which they must be performed.  Task sequence is typically based upon task prerequisites and dependencies and upon the natural workflow order of tasks, and may also be based upon resource availability.

In the project schedule, each task has an estimated level of effort and is assigned an owner (i.e. the task owner) who is responsible for completing the specific task.  Each task’s level of effort is used to estimate the task’s target completion date, which cumulatively roll up to indicate the project’s overall estimated completion date.

Typically, the project schedule is created using MS Project and is created by the PM, who may solicit help from the appropriate technical SMEs to define tasks, task sequence, and estimated effort.  When using MS Project, it has been our experience that managing a project schedule is a bit easier by aligning with a few key concepts:

• Organize task sequences by specifying downstream tasks as dependents of upstream tasks (instead of hard-coding task start/finish dates), so if an upstream task’s level of effort changes then the estimated start/finish dates for all downstream tasks will automatically adjust.
• Estimate tasks in terms of effort (i.e. how many hours a task would take if an SME worked on that task full-time), not duration (i.e. how much time will elapse in order for the task to be completed). In doing so, do not attempt to estimate a task’s level of effort in increments of less than four (4) hours (sometimes two (2) hours is okay depending upon project size and complexity), since on an ongoing basis, it can be very cumbersome to try to manage smaller levels of granularity.
• Take a moment to identify tasks on the critical path (the lengthiest sequence of dependent tasks that, taken together, represents the minimum amount of time (effort) required to complete the work package), as this can help identify tasks that may be able to be performed in parallel (vs. sequential) to accelerate project estimates and indicates the soonest possible time the project can be completed.

The primary outcome of this level is a complete project schedule that contains all work packages and associated tasks, estimated levels of effort, and task owners.  The PM should use the project schedule to manage day-to-day project activities.

In Conclusion

Ferroque MSP and PS teams are fluent in engaging at all levels of the customer’s organization to assist with all efforts outlined in this blog and would be happy to discuss engagement opportunities with you.