The place where I like to capture client expectations is in the Project Scope and Charter. This document is closely linked to the workplan. The workplan is where expectations are turned into tasks, deliverables and milestones that will help meet those expectations. There isn’t a sequential order implied between defining the work and building the schedule and budget. Therefore, you can work on the Project Scope and Charter and the workplan simultaneously.

Some of the sections of the Project Scope and Charter, such as the estimates for effort and duration, cannot be completed without starting to lay out the overall project schedule. At the same time, you cannot complete the schedule without gaining agreement on the Project Scope and Charter. For instance, you cannot build the schedule and budget without gaining a high-level agreement on deliverables and scope. Defining the expectations for the project also involves describing an overall project approach, which is helpful to know before the schedule is completed.

You will find that as you gather information about scope and deliverables, you can start laying out a high-level schedule. As you gather more information about the work, you can fill in more details on the schedule. When the deliverables, scope, assumptions and approach are complete, you should have enough information to complete a high-level schedule. You can then use the high-level schedule to estimate the necessary budget, effort and duration - which in turn are used to complete the Project Scope and Charter.

At the end of the Plan the Work phase you should have an agreement with your sponsor on the work that will be completed and the cost (time) and duration that are needed to complete the work. These three items then form a concept called the “triple constraint”. The key aspect of the triple constraint is that if one of the three items change, at least one, if not both, of the other items need to change as well.

If the scope of work increases, the cost and / or deadline must increase as well. If you have more work to do, it will take more cost (effort) and perhaps a longer duration. Likewise if you reduce the scope of work, the cost (effort) and / or the duration should decrease as well. If you are asked to accelerate the project and complete it earlier than scheduled, it would also be logical to ask for less work. However, if you are asked to deliver the same work with less duration, the third leg of the triple constraint must increase to maintain the balance. You will need to increase costs (effort), perhaps by working overtime hours or perhaps by bringing in more resources to complete the same amount of work earlier.

These conversations are easier to have with your client if you’ve correctly captured their expectations. And capturing these expectations up front becomes critical to the success of planning any project. Without understanding or, properly capturing these expectations you’re not able to provide project management to your client. And we all know how that story ends!

But it required a pretty specific plan and we had to stick to the plan even though we knew we wouldn’t be looking at the end product in 90 days.  In it’s basic form we had i. a plan with critical milestones and ii. what I’m calling “building blocks” (i.e., framing, plumbing, electrical etc).  We had to make sure that each of the building blocks was fully defined ahead of time (i.e., framed walls went here and not over there) and mapped out on the timeline to fit it in the 90 day window.  Since I was the one managing the workplan I actually ended up switching the tasks around and going against the traditional order followed in construction.

Now, use the same analogy but apply it to HFM.  You will have i. a 90 day plan with predefined milestones….that comes from us, and ii. your building blocks (i.e., COA, entity structure, client list, products, business rules etc)….that comes from you.  Once we have all the building blocks defined we can assemble your application in 90 days assuming you stick to the plan!  What I find the hardest part of implementing HFM is the definition of your building blocks.  Take the chart of accounts for example.  The number of iterations that the chart will go through during a development cycle will surprise you and also extend the development timeline as these refinements are made in an effort to get everything 100%

So, what if we gave you a chart of accounts as a starting point based on your industry?  What if we gave you this chart and then showed you a format that we needed it in to be considered a “building block”?  Now repeat this process for all the other components and there you have all the pieces for your new application.  Using the timeline we provide and manage to you have the ability to be up and running within 90 days!  Will your application include multiple reporting structures and complex items like Cash Flow on day one….probably not…..but you’ll be up and running! What’s even cooler is that Phase II won’t be that far behind with the additional reporting detail that you need to have your final product.

The onus will be on you to stay within the 90 timeline and complete construction on your house.  Or, you may decide to move a wall or two understanding the consequences to the timeline as a result.  At the end of the day it’s your decision….but you do have the option to move in after 90 days putting the final trim work on at a later point in time.

First you have to identify the applications that are suitable for developing and maintaining remotely. Not all situations will fit this criterion due to security and procedures around administering certain applications and/or environments. I’d say 95% of the time this is not an issue however; I’ve been at some financial services clients where AMO was not an option.

Second, you need to know the company you outsource too. More importantly they need to know you and know your business. Outsourcing for the sake of outsourcing or, saving money is in my opinion short sighted and misses the concept of outsourcing all together. Most Hyperion Financial Management applications are considered mission critical due to the impact they can have on the close cycle of a company and therefore, share price. Do you really want to hand that responsibility over to ‘cousin Vinny’ because he’s 10% less than a more reputable firm?

Either way, you’ll need to develop a Service Level Agreement (SLA) that covers all situations. Furthermore, you need to realize that you’re handing over the keys! Whether you like or not, the provider you just gave the keys to became a partner and trusted advisor to you and your company! Make sure you have the procedures in place to ensure success and the capability to monitor that success.

Last, make sure that the provider you give the keys to is flexible and supports your business processes. Not the other way around! This should be reflected in your SLA as well as the measuring and monitoring of performance against that SLA. If you fit the above requirements then it’s worth looking into AMO to explore further if it’s right for you. If it is, there are some significant benefits that will help position you for short term as well as long term success.

For more information on AMO or, to see if outsourcing fits your needs please contact Rick Cadman 416.977.2229.

Bottom line, everyone does it a little differently. If you follow an industry standard PMBOK Methodology you’ll find that there are 4 four common components to managing projects and managing project processes:

• Scope Management
• Issue Management
• Risk management
• Quality Management

So, how do I differentiate between being effective and having mounds of paperwork? Break project management down into the basic components above and then analyze the cost and the benefit of each component with your client. It doesn’t get simpler than that. You’ll have to come up with what the costs are with managing each component; usually pretty straight forward based on applied hours. However, the benefits are usually the costs of not doing something or, doing something incorrectly! Benefits are usually harder to quantify. To me, this becomes the differentiator between going deep with project management and not going deep enough.

Experienced project managers will apply the art in these situations and draw upon past experiences to balance the success of the project whereas new project managers will apply the science.Whether you’re a project management newbee or a PMP certified guru the most important element is communication with your client. Understand how each of the components will be applied and how they will be measured. The rest you can adjust as the project progresses.At the end of the day, if the client is happy with the way scope, issues, risk and quality are being monitored and measured you’ve found the art using the science!

The purpose of scope change management is to protect the viability of the approved Project Scope and Charter and the approved business requirements. In other words, the Project Scope and Charter defines the overall scope of the project, and the business requirements define the deliverables in detail. The project team committed to a deadline and budget based on this high-level and detailed scope definition. If the deliverables change during the project (and usually this means that the client wants additional items), the estimates for cost, effort and duration may no longer be valid. If the sponsor agrees to include the new work into the project scope, the project manager has the right to expect that the current budget and deadline will be modified (usually increased) to reflect this additional work. This new estimated cost, effort and duration now become the approved target.

Sometimes the project manager thinks that scope management means having to tell the client ‘no’. That makes the project manager nervous and uncomfortable. However, the good news is that managing scope is all about getting the sponsor to make the decisions that will result in changes to project scope. This is very important. Few clients can see and express every requirement up-front. Therefore, there are usually changes that need to be introduced during the project. These changes may be very necessary for the solution and there may be valid business reasons why they should be included. The project manager and project team must recognize when these changes are requested. Then they must follow a predefined scope change process. This process ultimately brings the appropriate information to the project sponsor and allows the sponsor to decide if the modification should be approved based on the business value and the impact to the project in terms of cost and schedule.

Identify scope change request

Solicit potential scope changes from any project stakeholders, including the project team, clients, sponsors, etc. Potential scope changes should be documented in writing to the project manager through a short Scope Change Request Form (optional) or email.

Validate it is a scope change.

The project manager validates that the request is, in fact, a scope change.

Enter the request in the Scope Change Log

Enter the item into the Scope Change Log for tracking purposes.

Request the business value of the change

The person making the scope change request should define the business value to the project. The sponsor will need this information to make a final decision.

Determine the impact of the investigation on the project

The project manager must estimate the impact of the investigation to the project in terms of effort, cost and duration. If the time to investigate the impact of the change is minor, the project manager will proceed. If the time required to perform the scope investigation will cause deliverable dates to slip, the request must first be taken to the project sponsor to determine whether the request itself should even be investigated. If the sponsor gives the initial approval to proceed, the schedule and budget may need to be updated to reflect this new scope change investigation. If the sponsor does not agree to investigate the change request, then the request should be closed as ‘not approved’ on the Scope Change Log.

Assign the scope change to a project team member for investigation

The project manager could assign it to himself.

(Optional) Resolve small change requests if there is no impact on schedule and budget

If the impact on project cost, effort and duration falls below a threshold (say less than 20 hours) and the project will still be completed within the agreed upon cost, effort and duration, the project manager and client manager may approve the scope change request. This threshold needs to be identified and approved in advance by the project sponsor. The purpose of this step is to keep from sending many small changes to the sponsor for approval. However, the sponsor must have agreed to delegate this responsibility - usually up to a certain threshold of dollars or effort.

Take the information to the sponsor

Take the scope change request, alternatives, business value and project impact to the project sponsor for a resolution (if the project manager and client manager did not approve, as above).

Document the resolution on the Scope Change Log

Close out the change request on the Scope Change Log with the final resolution.

Close the Scope Change Request Form

The project manager should update the Scope Change Request form and then close and file this document.

Update the schedule and budget

If the scope change request is approved, the appropriate activities are added to the schedule to ensure the change is implemented. The project budget and deadline should also be updated, if necessary.

Update the Project Charter, if necessary

The current Abbreviated Project Charter should be updated if an approved scope change results in a substantial change to the scope of the project.

Communicate through your Status Reports

Communicate scope change status and resolution to project team members and other appropriate stakeholders through the methods established in the Communication Plan, including the project Status Report.

Identify the problem

Solicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means.

Determine if the problem is really an issue

The project manager determines whether the problem can be resolved or whether it should be classified as an issue.

Enter the issue into the Issues Log

If it is an issue, the project manager enters the issue into the Issues Log.

Determine who needs to be involved in resolving the issue

The project manager determines who needs to be involved in resolving the issue. The sponsor may be involved, or the sponsor may not have the expertise to assist in the resolution process. For instance, the resolution may require technical or legal staff. The problem may be contractual and require resolution from the Purchasing Department. However, at some point the alternatives will be discussed and a resolution will be made. It is important to understand up-front who needs to be involved in making this final issue resolution.

Assign to team member for analysis and alternatives

The project manager assigns the issue to a project team member for investigation (the project manager could assign it to himself or herself). The team member will investigate options that are available to resolve the issue. For each option, the team member should also estimate the impact to the project in terms of budget, schedule and scope.

Gain agreement on resolution

The various alternatives and impact on schedule and budget are documented on the Issues Form. The project manager should take the issue, alternatives and project impact to the project sponsor and other appropriate stakeholders for discussion and resolution. The project manager may want to make a recommendation from among the alternatives as well.

The project manager documents the resolution or course of action on the Issues Log.

Close the Issues Form

The project manager documents the issue resolution on the Issues Form and then closes and files this document.

Add action plan to the schedule

Once a resolution is agreed upon, the appropriate corrective activities are added to the schedule to ensure the issue is resolved.

Update Project Charter, if necessary

If the resolution of an issue causes the budget, effort or duration of the project to change, the current Project Charter should be updated.

Communicate through the Status Report

The project manager communicates issue status and resolutions to project team members and other appropriate stakeholders through the methods established in the Communication Plan, including the project Status Report.

The project manager should perform a risk assessment with the project team and the client to identify high, medium and low level risks. The project manager should perform a risk assessment with the project team and the client to identify high, medium and low level risks. There are two ways of tracking risks. You can manage the risks on your project using an Issues and Risk Log. Or, for a larger project you can develop a Risk Management Plan.

Create Risk Management Plan

Start the risk management process by understanding your overall approach for managing risks. This includes defining your risk management process, who is involved with the risk management process, what tools will be used, what roles will be involved, if any (project manager, risk officer, risk manager, etc.), the timeline and the effort associated with managing risks, the risk techniques to be used, etc.

Identify all potential risks

When you are defining the project, perform a complete assessment of project risk. The risk assessment is done in two parts. First look at inherent risks. These are the risks that are inherent to your project based on its general characteristics.

For example, a project that is estimated to take 10,000 effort hours is inherently more risky than one that is estimated at 1,000 effort hours. A project that has 20 people is inherently more risky than one with 3 people. A project that is using new technology is inherently more risky than one that is using technology your team is comfortable with. Notice that in each of these examples, you do not need to know the specifics of the project.

Inherent risks are based on the characteristics of the project - regardless of the specific deliverables being produced. The good thing about these inherent risks is that, since they apply to all projects, they can be identified on a checklist. Second, look for risks that are specific to your project. These risks normally cannot be identified on a checklist since they are specific to your project and may not apply to other projects. For instance, you may identify a risk of a key supplier going out of business or perhaps weather problems causing shipping delays or perhaps you will have difficulty finding resources with a specific set of skills.

There are a couple ways to perform the risk assessment. The project manager can create an initial draft of project risks based on what he knows and circulate the draft for additions, changes and comments. Another technique is to gather all the key stakeholders and discuss these potential risks of the project all at once. This is a better alternative since it gets the key stakeholders all thinking about the project at the same time. You are more likely to end up with a more exhaustive list of real project risks. You want to be careful about being too optimistic during the risk assessment.

Remember, you are trying to identify potential risks. It is good to have skeptics or pessimists in these sessions to make sure that all of the potential risks are identified.

Analyze the risks using qualitative techniques

In the first step of this process you identified all potential risks. This will likely leave you with many more risks that you can focus on. In fact, it probably doesn’t make sense to focus on managing risks that have a low impact to your project. Therefore, before you go through the trouble of putting risk plans in place, you need to determine which risks are the ones that you really want to focus on. The first step of risk analysis is qualitative risk analysis.

(Optional) Utilize quantitative analysis for all high-level risks

Next, determine if you will utilize more formal and rigorous quantitative risk techniques for the risks that you identified as high-risk using qualitative techniques. The term “quantitative” means that the risk levels are based on a numerical analysis rather than on approximations such as low, medium and high. There are many models and algorithms that can be used for quantitative risk analysis. Most projects, even large ones, do not need to utilize quantitative techniques. However, some projects do require these formal techniques. For instance, if you were building an airplane, it would not be good enough to classify risks into general high, medium and low categories using informal qualitative techniques. You would definitely need the more sophisticated modeling and statistical risk analysis techniques that are a part of quantitative risk analysis.

Create a response plan for each high-level risk

Create a response plan for each high-level risk that you identified to ensure the risk is managed successfully. This plan should include activities to manage the risk, as well as the people assigned, completion dates and periodic dates to monitor progress. There are five major responses to a risk - leave it, monitor it, avoid it, move it to a third party or mitigate it.

Create a contingency plan for high-level risks

Create a contingency plan to document the consequences to the project if the Risk Management Plan fails and the risk actually occurs. In other words, identify what would happen to the project if the current risk turns into a future issue. This helps the project manager ensure that the effort associated with the Risk Management Plan is proportional to the potential consequences. For instance, if the consequence of a potential risk occurring is that the project will need to be stopped; this should be a strong indication that the Risk Management Plan must be aggressive and comprehensive to ensure that the risk is managed successfully.

Evaluate the medium-level risks

Evaluate the medium-level risks to determine if the impact is severe enough that they should have a risk response plan created for them as well.

Evaluate any low-risk risks

Look at any low-risk items and see if they should be listed as assumptions. In this way you recognize that there is a potential for problems, but because the risk is low, you are ‘assuming’ that the condition will not occur.

Move the risk plan activities to the project schedule

Move the activities associated with the Risk Management Plans to the project schedule. Moving the activities to the schedule ensures that the work is actually completed and keeps the schedule the primary focus of all work planning and monitoring.

Monitor the current risk plans

The project manager needs to monitor the Risk Management Plans to ensure the risks are successfully managed. New Risk Management Plan activities should be added if it looks like the risk is not being managed successfully.

Look for new risks

The project manager also needs to periodically evaluate risks throughout the project based on current circumstances. New risks may arise as the project is unfolding and some risks that were not identified up-front may become visible at a later date. It is also possible that previously identified, lower level risks may become medium or high risks at a later time. This ongoing risk evaluation should be performed on a regular basis or at the completion of major milestones.

Determine the client requirements for quality

Work with your client to determine their requirements for quality. These are the detailed characteristics that are important to the customer. The high-level characteristics of quality can be uncovered during the project definition process. The detailed quality requirements should be uncovered when you gather business requirements.

Create a Quality Plan

Develop a Quality Plan to identify the major deliverables, completeness and correctness criteria, quality control activities and quality assurance activities. The Quality Plan allows you to understand when the deliverables are complete as well as how to show they are correct. The Quality Plan also describes how you will ensure that the client’s quality requirements are achieved. It is the place to describe the processes and activities that will be put into place to ensure that quality deliverables are produced. The Quality Plan describes the quality assurance and quality control activities used on the project. The actual activities needed to implement these processes need to be identified and included in the schedule to ensure they are completed.

Define a set of metrics to validate quality requirements are met

Identify a set of metrics that will provide insight into the progress of the project and the processes used to create deliverables. The project manager should already be capturing overall financial and duration metrics. The quality-related metrics need to be more sophisticated. There are two areas where you are trying to manage quality - in your project work processes and in the actual deliverables you are building. You should try to capture metrics that will measure each.

Execute quality assurance activities

During the project, conduct all of the quality assurance activities as specified in the project schedule.

Execute quality control activities

Ensure that the quality control activities for every deliverable are performed while the project is underway. At a minimum, you should have a visible deliverable review process.

Update and monitor the Quality Plan

Evaluate the Quality Plan on a monthly basis or at the completion of major milestones. The review should focus on whether the Quality Plan is still adequate to ensure that the project deliverables are completed within the quality expectations of the client. If it is not, update the Quality Plan with changes and update the schedule with any new or modified activities required.

Collect metrics to validate you are meeting quality requirements

During the project, capture the metrics. Most should be captured monthly. Some, like client satisfaction surveys, may be captured quarterly. If you are building or manufacturing something tangible, you may want to collect automated product-based metrics every day.

Analyze metrics for process improvement opportunities

Analyze the metrics to determine how your project work processes can be improved. For instance, the deliverable review process might be changed from one review when the deliverable is completed to add an extra review when the deliverable is 50% complete. The time required for this draft review might be more than offset by dramatically reducing errors found when the deliverable is complete. In another example, for a manufacturing process, you may need to upgrade equipment, send the operators to more training or invest in better raw materials.

Analyze and resolve quality related problems

When quality problems are found, implement a process to determine the cause and to make improvements in the process.

Implement the improvements that were identified

There may be more ideas than you can safely implement in one review cycle. If you find that to be the case, prioritize the suggestions and implement those that seem to have the highest value but require the least amount of work. You may be able to implement other ideas on the next review and analysis cycle.

Continue to measure

You may need to identify new or revised metrics to support new or revised work processes.

Review key learnings at the end of the project

At the end of your project, provide feedback to the organization on the results of your quality process and report the final metrics captured. These can be leveraged for an organization-wide metrics program and provide input into best practices that can be used again on other projects. This step is bypassed if your organization does not collect standard project metrics.

This tutorial will show you how to register and import the Hyperion Financial Management (HFM) Adapter for Financial Data Quality Manager (FDM). This is one of the first steps to complete after creating a new FDM Application to get you up and running.

Supported Versions

This tutorial has been performed on Hyperion Financial Management System 9 (v9.3.1)

Start by Opening FDM Workbench and Logging In

Open your FDM application to get started. At the bottom left of the Workbench, click on the Adapters tab to get the screen shown below. For new applications, there shouldn’t be anything listed under ‘Target System Adapters’

Register the Adapter

The registration portion of the HFM Adapter involves registering a DLL (click here to learn about DLL files) file into Windows registry. This step might have already been completed if other applications exist on the same computer. To register the DLL file if it hasn’t been registered already go to File > Register Adapter to find the DLL file (The DLL file can also be registered outside of the Workbench by using the windows command regsvr32.exe)

Locate DLL file for Adapter

The HFM Adapter has a filename that starts with upsFMxxxx.dll. For Hyperion Financial Management 9.3.1 the file should be named upsFM9xG4A.dll. The DLL file might not be in the default directory that’s open by the Workbench. To locate the DLL, ask your system administrator where they’ve stored it, or simply search the Hyperion installation directories for DLL files starting with upsFM.

Successful Registration

If the DLL register successfully you should see the following message (note that all the Workbench is doing is running regsvr32.exe).

Import Dimensions

At this point, you’ve only registered the DLL file into the Windows registry. Nothing should show up in your Target Adapters list just yet. To import the dimensions, and Adapter code select File > Import.

Locate XML Adapter file

There should be two XML files named FM9x-G4-A.xml and FM9i-G4-A.xml in the same directory as your DLL file that you registered earlier. To determine which XML file to load, there should be a readme file in the same directory explaining the differences between the two. In our case, we’re going to import the FM9x version.

Select What to Import

Select what you want to import in the following screen and go over the options in the Options tab.

Updated Adapter Dropdown

Your HFM Dimensions and Machine Profile should show up in your list now as shown below.