Goal Alignment and Solution Planning

Define the Problem or Opportunity

The first step in any new request is to define the problem or opportunity being addressed. There are a series of questions that can help define the request, as follows:

Note: If the problem or opportunity is being stated as a solution, ask the question “why” until you get to the root of the problem or opportunity. This section should not dictate solutions, although possible desired solutions may be added once the problem has been stated.

Intake Categorization Questions:
 

• Is this request for an enhancement, new development, unknown, or other (please specify)?

• If an enhancement - which application and technology is the current solution using (if known)?

• Please indicate the businesses or functions this solution will support.

• Who and how many users will this solution support (if known)?

Other potential questions:

1.       What is the problem or opportunity this request will address?       

2.       Describe or list the goals and deliverables that are to be achieved from this request. List in order of priority.
 

Note: Goals should be broad statements that describe desired outcomes, and are generally not quantified. However, they should keep the scope in mind and be generally measurable. Objectives will be reviewed later, which will detail specific, measurable targets toward reaching these goals .An example of a well-written and poorly written goal is:

Poor: To provide good roads (too general)

Better: To provide road surfaces that ensure a smooth and comfortable ride for people and goods traveling in the state by automobile

Poor: To continue to serve our customers (not challenging and doesn’t clarify the mission)

Better: To provide health benefits plans that are affordable to both our members and state agencies (example for a health care organization)

Poor: To reduce by 15% the amount of contaminants in our drinking water by the year 2006 (time-bound and too specific – this is an objective, not a goal)

Better: To ensure safe drinking water quality for all citizens of our state and those served by public water supply systems.

Note that, in the examples above, the well-written goals were broad, but gave a sense of scope limitations and were specific enough to act as drivers for developing solutions and objectives.

3.       Are there any special user, functional or interface requirements?          
 

4.       For software, are there reporting requirements?   If so, what type of reporting is needed?

5.       If this request is an enhancement or redesign, where does the data live today?      

6.       Is there a requirement to migrate data?  What criteria must be taken into consideration for data migration?

7.       What are the data security requirements? For example, will varying security levels be required by business, business role, user groups or dept?    Please explain.    

8.       What options to date have been considered for the solution?  If any, is there a favored option? Describe why it is the most attractive.                     

9.       Are there any hard constraints around cost or time?         

10.     Is this project part of a larger initiative or strategic goal? If so, what is that initiative or goal?

11.     Are there any specific target goals driving this initiative? If so, where did these targets originate and how will they be measured?

12.     What is the cost of delaying or not doing the solution, or being deficient in the desired functionality? Quantify where possible.            

13.     Are there any incentives or penalties for early or late completion of the project? If so, please explain?

14.     Who are all the internal and external stakeholders that may be impacted (positively or negatively) if this problem or opportunity is addressed?

15.     Will any stakeholders have to do anything as a result of this project (i.e. invest time, money, change work processes, install equipment, etc.)?
 

Deliberate Goals and Objectives

Once the request has been clearly defined in terms of its goals, impact, and stakeholders, the next step is to outline the goals and underlying objectives, and to undertake a meeting or series of meetings to make sure everyone is on board with the goals and objectives.

Consider the size and complexity of the project and decide how many meetings goal deliberation should require (and whether goals and objectives can be reviewed and agreed upon in a single session).

Note: The goal and objective deliberation process can be less formal for smaller projects, but the same thinking-steps should be done, and the sponsor and key stakeholders should still be consulted.

In preparation for this step, it’s important to gather any additional related information as appropriate (e.g.  Current as-is state, current processes, system background, information about key players, related projects, etc.)

Once the goals have been deliberated, prioritized, and agreed-upon, the next step is to deliberate the specific objectives. Objectives should be SMART (Specific, Measurable, Aligned, Realistic, and Time-Bound). They should be aligned with the identified goals.

Generate Alternatives

Once the goals and objectives are defined and agreed upon, the next step is to determine the alternate solutions to addressing the objectives (including doing nothing). To do this requires a cross-functional team that some organizations call a Solution Review Team or Solution Planning Team. Sometimes this is a permanent team, but often it is a virtual team made up of select individuals from across the organization. When assembling the Solution Planning team, be sure to consider:

• Subject Matter Expert representation from a cross-section of solution delivery organizations, including:

o   Software application development

o   Business function/process representatives

o   Technology/Infrastructure representatives

o   Customer Service

o   Others as appropriate

When analyzing alternatives and their risks, use the checklist below for things to consider.  Not all of these questions need to be answered, but all should be considered to determine their relevance to the project being requested.

Technology:

• What technology is being considered for this project?Is it new in the industry?Is it new to the organization?

• Where is this technology in the organization’s IT technology roadmap? If the solution is not part of the standard enterprise software/technology suite, is there a compelling reason why?

• Is this a known “throw away” deliverable (short life cycle)?

• Are there licensing requirements or other restrictions to use?

   

Security:

• Are the any access issues that will need to be addressed with the implementation of this solution?

• Are there any proprietary information issues that need to be addressed?

• Will access need to be provided for external resources; customers, suppliers, external partners, others?

• Are there any business controls or segregation of duties issues that will need to be addressed?

• What business interruption/continuity issues need to be addressed?

Delivering Business Process Functionality:

• What process functionality is being delivered by this solution?

• Does this need/problem exist in other businesses and how are they solving it today?

• Is it new or a change to existing functionality?

• Will elements of the business need to reorganize around the delivered solution?

• What is the extent of the changes that will take place; new to some, not new to others?

• What are the connection/interfaces and impact to other business processes?

• What hardware, software, custom development may be required to implement the solution?

• How much testing has to be done and who needs to participate?

• Is there training that needs to be developed and delivered?

• Will other business/functions within the organization be able to use this solution?

Capacity:

• Are there any capacity issues that need to be addressed; users, bandwidth, storage, computing power, response time, transactions?

Risk Management:

• What is the technical risk of the solution?

• Will the solution provide all the required functionality?What is the impact if it doesn’t?

• Will the users use it? What happens if they don’t?

• Will user representatives commit to adequate testing?

• Will appropriate management reps be available for review and signoff? What happens if they’re not available or unwilling?

• What is the priority of investment vs. total cost of ownership, delivered functionality, schedule, and risk?

Cost:

• What is the total cost of ownership of the solution (including ongoing support and maintenance)?

Determine Solution(s) and Approach

Ideally, the previous step would have brought forth at least one recommended solution and possibly several.  The next step is to weigh the various solutions.

Use a grid similar to the following to list the possible alternatives (along with benefits, risks, and a conceptual estimate). If trying to avoid capital spending, include non-capital alternatives if possible. It’s often good to include the “do nothing” alternative for comparison.

The final activity in this step is to produce a Solution Recommendation report, consisting of the following:

• Summarize the chosen solution(s), and why they were selected:

• List the items that are in and out of scope for the chosen solution(s) – as much as is known at this point and as adequate to offer a conceptual estimate (-25%/+50%). This will be elaborated during project planning, once approved.

• Describe the approach that will be used for managing the project (i.e. Phased Deliverables, Rolling Wave Planning, Agile, SDLC, Stage Gate, Six Sigma, etc.):

• List the roles established for the project, and those that will be required to proceed with the chosen solution(s). Be sure to include:

• Requester(s)

• Sponsor(s)

• Project Manager

• Key Contacts/Subject Matter Experts

• Others (add as needed)

If necessary, revise the stated objectives to align with the chosen solution (do this only with the sponsor’s and customer’s approval).

Once the report has been submitted and accepted, confirm that the sponsor wants to proceed to Governance and a full business case for the recommended solution.

Begin working on the Business Case and Scope Statement, with input from the Project Sponsor.

Related Planview Functionality

Content Management  – Planview Enterprise’s Content Management enables users to store and share documents, where guides or worksheets for Goal Alignment and Solution Planning processes can be kept.

Lifecycles– Planview Enterprise’s Lifecycle workflows can include steps in the demand intake or project initiation process to ensure that Goal Alignment and Solution Planning processes have been executed. Lifecycle roles can be created for the appropriate parties as necessary, such as Solution Planners responsible for reviewing and presenting alternatives.