1. What is the difference between a Project Management Framework and a Product Development Life Cycle?
The Project Management Framework
Includes the activities needed to manage a project.
Activities remain the same no matter what product or service the project delivers.
The Product Development Life Cycle
Includes activities to analyze, design, build and implement a specific product or service.
Activities vary depending on the type of product or service being developed.
Project Sizing Questions:
1. How will the Project Management Advisor (PMA) accommodate small, medium and large projects?
PMA provides guidelines for determining project size. Although PMA will not be available in versions by size (this would be costly to develop and maintain and likely would be confusing to users), PMA does include several navigation paths, which should provide for effective and efficient use of the content. Additionally, the templates and examples in PMA contain a simplified form for small projects. For small projects, see Project Charter/EZ, Project Plan/EZ, and Status/EZ. The “EZ” examples illustrate how to create simple documents for small projects. For medium or large projects, see Project Charter, Project Plan, and Status.
2. Can a project manager decide that a particular component of a document template is not applicable to the project?
Yes. All documents are designed to be flexible and to allow individual project managers to decide what to include in consultation with their project sponsors. Project managers should refer to Determine Project Size, decide how to apply the criteria to their projects, and consult with their project sponsors if there are questions.
3. When should I use the EZ versus the long form of the project management stage deliverables?
4. What is the difference between a task and a project?
Many support activities fit the strict definition of a project: they have a purpose, an outcome, a start and an end date. Some of these tasks, such as applying a single bug fix, do not need to be treated as projects. However, many service teams and other support services generate activities that should be treated as projects. Examples are: apply a major upgrade to a software product; modify a network or server configuration that impacts multiple services or customers; make a set of enhancements to an application or service developed by DoIT.
5. Are any projects so small that the project management framework does not apply?
All projects should follow the project management framework. The Determine Project Size guidelines are provided in PMA to clarify the extent to which the framework activities and deliverables are used based on project size. See above for the difference between a task and a project.
6. Will project management guidelines for internal DoIT projects differ from projects for an external customer?
No. The same principles apply for good project management of all projects.
Change Management Questions:
1. What is the purpose of a change budget?
Establishing a change budget is a useful way of reigning in the desire to tinker with scope. The customer agrees ahead of time to the discipline of staying within the change budget in exchange for commitments to schedule and/or cost. The change budget gives the customer a way of gauging the amount of change introduced to the project and rationing future change approvals.
A contingency budget should not be used to pay for changes. A contingency budget mitigates uncertainty for a given scope and set of risks. By spending down your contingency budget on changes, you obviate your risk strategy without removing the risk. A better approach is to secure the additional funding needed for the changes and/or to revise the risk management plan to reallocate the contingency budget and to deal with the risk in some other way.
2. How should I handle project changes vs. informational changes?
Not every change that occurs in a project needs to run through the change management process. Informational changes, defined as those that do not impact the project baseline, may simply be noted in project reports. A change in staff without a change in roles is an example of an informational change.
3. Should the change management plan address changes to budget and schedule?
While controlling scope creep is perhaps the first thing that comes to mind when managing change, changes to budget, schedule, and other project plans can impact the overall success of a project and should receive the same careful attention as scope. Many projects, in fact, are driven by cost, budget, or quality.
4. What is a non-compliance change and how should it be handled?
A non-compliance change occurs when someone fails to deliver work on time, within budget or per specification. While you don’t “approve” the non-compliance, you do have to evaluate impact and approve the action you propose to take to compensate for the non-compliance.
5. How should I track issues and change requests?
Issues are facts; changes are actions taken often because of these facts. Issues and changes are different things with different attributes and associated processes. See the Issue Management Plan for more information about issues.
6. How can I tell how much effort will be required to manage change?
Managing change in a project can consume considerable staff time and energy. The change volume projection helps planners set appropriate resource allocations and budgets to handle this work. The projection may also be used to help team members determine when they need to be available to perform their assigned change management tasks (e.g. evaluation or approval) in a timely manner.
7. Does the project team need to be trained in change management practices?
Yes, plan to train the project team on how change is to be managed, particularly if your change management approach is tailored for your project.
8. What is the difference between change management for projects and change management for the operational framework?
DoIT’s Project Management Framework
Defines how to manage a project.
Classifies and organizes project management concepts and methods.
Guides the project manager through project management activities.
Contains five project management stages.
Each stage includes activity definitions, templates, and examples.
Stage 2 – Initiate, Stage 3 – Plan, and Stage 4 – Execute and Control each include a component of the Change Management process for projects. Changes can occur at any point in the project life cycle. Unmanaged change can cause a project to fail to meet its objectives. The key to success is to permit changes to the project during the Execute and Control Stage through a deliberate and controlled process in clear view of the project team, the sponsor, and the stakeholders. A strategy is defined in the Initiate Stage and specifics of the process to be followed are defined in the Plan Stage.
DoIT aims to improve the operational processes used to support DoIT provided services, and to potentially implement a wider operational framework. DoIT’s Operational Framework addresses Change Management and Incident Management. The overriding goal of these processes and related standards is to ensure best-possible operational efficiency, service, and uptime. The objectives of IT Change Management are to:
Increase the availability & reliability of DoIT’s computing infrastructure,
Set accurate customer expectations regarding change impact,
Minimize the negative impact of changes to customers, and
Enable network operations to move beyond reactive operation.
Change Management within the Operational Framework delivers the processes and techniques required to allow DoIT to manage change associated with its Network, Hardware, Software, Application and Documentation Configuration items (CI’s). In this context, change management controls the introduction of change into an information system environment. It provides a detailed list of changes being scheduled to allow for balancing workload and resources.
Issue Management Questions:
1. What is the relationship between project issues, risks, and changes and the management of each?
Issues are different from but related to risks and changes. A product defect, an assumption that proves to be unfounded, and a suggestion from a team member are examples of issues. Not all issues are negative.
When a project risk is realized, if the planned resolution of the risk does not succeed, then its impact may become an issue that must be dealt with. Similarly, the resolution of an issue could result in a change request to be submitted to the change management process. But while this interplay between issues, risks, and changes is common in most projects, the work you do to manage each is different.
Issue management involves recording and prioritizing, tracking, escalating, resolving, and reporting unplanned events. Fundamentally, issues are raised and subsequently resolved as part of the routine management of the project, often with no change required to the project plan. However, with the anticipation and subsequent occurrence of possible deviations from planned outcomes (risk management), and with issue resolutions that result in change to the project plan (change management) the project manager should refer to the specific guidelines for managing risk and for managing change to guide decisions and actions.