Intake, Initiation, and PM Methodology

In this category, you will learn about project intake, including entering project ideas in the PPM tool, performing due diligence, and writing Capital Authorization Requests (CARs). You will also learn about the various project methodologies (Agile-Scrum, Agile-Kanban, Agile-Hybrid, and Waterfall) that help drive stakeholder analysis, resource management, and project communication plans.

Project Intake

The Project Intake Process is recorded in the PPM tool as a Project Request. A bi-weekly Project Council meeting takes place in order to review project ideas to ensure there is no duplication of effort and to allow for resource planning and strategy alignment.

The goals of the Project Intake Process are to:

• Govern business initiatives requiring IT investments from ideation to launch
• Provide a decision point before committing to project execution
• Engage key stakeholders at the appropriate time to drive value-based prioritization
• Provide a flexible process focusing on higher priorities and bigger investments and resulting in a higher return and faster time to value
• Ensure initiatives are business-led, with a clear link between initiatives and business strategies, goals and metrics

Projects that must go through Project Council review include:

• New technology (outside of enterprise standards) and innovation
• Integrations/change of integration strategy
• Projects with resource dependencies involving key IT and CDS resources
• Decommissions of existing platforms
• Contracting/licensing vendor selection and strategic vendor partnership
• Consulting arrangements that involve technology recommendations or changes
• Customer-facing applications
• Data analytics initiatives

Change requests are not included in this process.

Due Diligence

Due diligence includes the key areas below:

Value, Benefits, and Risk

• A complete business case includes a clear value and benefits statement. Benefits need to be verified with Finance and must be categorized and tracked throughout the project
• Requirements and Project Success Criteria need to be measurable and documented in order to track the deliverables and success of the project
• The Project Sponsor and impacted stakeholders should be identified and must approve the project to initiate it
• An initial risk assessment is required and must include dependencies that could affect the project

Organizational Readiness

• An organizational readiness assessment includes validation from IT Security, impact on resources, whether any training is required, and possible organizational or process changes

Technology and Data Approach

• Includes any approval from the relevant groups depending on project scope (Enterprise Architecture, IT Security, Procurement)
• Could include vendor agreements, integration strategy, and new technology

Funding and Resources

• A CAR or Statement of Work must be created and approved to show funding is available and approved
• Resources are identified, and work is estimated and aligned

Requirements

Collecting requirements is the first step in defining a project’s scope and is one of the most important steps in a project. It builds the foundation for successful plans of detailed activities, timelines, costs, and resources needed. Capturing all the requirements for a solution up front reduces overall project risk and the likelihood of disputes and disagreements with our business partners. Moreover, assessing priority, criticality, and dependencies as well as defining a high-level estimation of the expected implementation workload for each requirement provides important information to the stakeholders who will ultimately determine the final scope.

Requirements must be validated to ensure the project’s feasibility and to ensure it will deliver its expected value to the business.

Requirements Characteristics:

• Correct: accurately states a customer or external need
• Clear: has only one possible meaning
• Feasible: can be implemented within known constraints
• Modifiable: can be easily changed, with history, when necessary
• Necessary: documents something customers really need
• Prioritized: ranked by importance of inclusion in the product
• Traceable: can be linked to system requirements and to designs, code, and tests
• Verifiable: correct implementation can be determined by testing, inspection, analysis, or demonstration

An unvalidated requirement is a bad or unnecessary requirement; if you cannot verify it, then you cannot design it or build it.

Formal acceptance of the requirements is needed and should be documented and tracked in the PPM tool.

Success Criteria

Defining your Project Success Criteria is a critical step because upon project closure, the Success Criteria will determine the success of the project.

Project Success Criteria refers to measurable outcomes of the project which are acceptable to the end user, customer, and stakeholders. Each criterion should be measurable in one of the following ways: performance, cost, schedule, and security.

When writing the Project Success Criteria, ask yourself:

• Is each criterion measurable (performance, cost, schedule, and security)?
• Has customer and stakeholder satisfaction been considered?
• Have user adoption requirements been considered?
• Is the criteria aligned to IT compliance (architecture, security, quality, etc.)?
• Is there benchmark data from current state to future state?
• Are there financial benefits or risks to be considered?

Involving the sponsors, customers, and other stakeholders during initiation creates a shared understanding of the Project Success Criteria, reduces the overhead of involvement, and generally improves deliverable acceptance, customer satisfaction, and other stakeholder satisfaction.

In addition to defining the Project Success Criteria, how it will be measured, how often, and who will be responsible for tracking it needs to be documented.

The PM is responsible and accountable for setting realistic and achievable boundaries (scope) for the project and for accomplishing the project within the approved project baselines.

Funding: Capital and Expenses

Capital Authorization Request (CAR)
The CAR is the official document used to gather necessary data and obtain approval for all capital projects. The CAR should include all required capital items necessary to achieve 100% of the benefits eventually expected from the project.

The CAR is typically initiated by the PM, the Business Partner, or the business division that owns the project, and the form can be found on Inside Ecolab.

The completed CAR must be sent to Finance for approval, and after approval has been given, a unique CAR number will be assigned by Property Accounting, and capital spending can begin.

You are encouraged to consult with Finance early on in the CAR process. CAR approval can carry over year over year if budgeted and according to the project timeline. Note that all CARs with IT components must be reviewed by IT.

Expense Funding needs to be raised as Purchase Orders (PO) or Statements of Work (SOW) and they also require Finance approval prior to spend. Expense dollars need to be budgeted/forecasted.

Project Methodologies

It’s important to select the right methodology for your project. In this section, we’ll look at Agile-Scrum, Agile-Kanban, Agile-Hybrid, and Waterfall.

Agile-Scrum

Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products. It allows participants to create and respond to changes using an incremental, iterative approach (rather than try to deliver everything at the end) in order to succeed in an uncertain and turbulent environment. It doesn’t have in-depth planning at the beginning of the project, allows for project requirements to change over time, and encourages constant feedback from end users.

The IT PMO recommends using Agile-Scrum on projects with the following characteristics:

• Success is defined by responsiveness to customer requests
• Requirements change frequently and there is quick turnaround
• The scope can change or be adjusted according to priorities
• Results can be incremental (e.g., software development or a data center move)

Agile-Kanban

Kanban is an Agile methodology that allows users to visualize the work that needs to be done on a given day on a board. The board is divided into columns of work to be done, work in progress, and completed work, and teams can add more categories as needed. Each task is represented on a Kanban card, and the cards are moved from column to column as the work is completed. Kanban is designed to limit the amount of work in progress so a team doesn’t commit to too much work at once and to optimize workflow by highlighting bottlenecks.

Kanban is particularly appropriate for situations where work arrives in an unpredictable fashion and/or you want to deploy work as soon as it is ready.

The IT PMO recommends using Agile-Kanban in the following circumstances:

• Short projects that need to move quickly
• Hypercare support
• Efforts that might not be considered a project but require team collaboration

Agile-Hybrid

An Agile-Hybrid methodology is generally used for projects that require extensive and detailed due diligence and planning. Once all requirements are identified and documented, the execution phase can be run as Agile-Scrum.

The IT PMO recommends using Agile-Hybrid on projects with the following characteristics:

• Requirements and due diligence require deep analysis and are not likely to change
• Work can be delivered iteratively but priorities will most likely remain the same
• The Product Backlog is expected to vary on priority but not requirements

Examples include process optimization, Windows deployment, and server refreshes.

Waterfall

Waterfall is a linear project management methodology where stakeholder and customer requirements are gathered at the beginning of the project, and then a sequential project plan is created to accommodate those requirements until execution. Each step of the Waterfall methodology must be finished before moving on to the next one.

The IT PMO recommends using Waterfall on projects with very specific requirements that are unlikely to change or on repeatable projects where the same concept can be utilized multiple times (such as office moves or remodels and hardware upgrades).

Stakeholder Analysis

Stakeholder analysis/management is the process of effectively engaging stakeholders throughout the project life cycle, based on the analysis of their needs, interests, and potential impact on project success. The key benefit of this process is that it provides a clear, actionable plan to interact with project stakeholders to support the project’s interests.

These are the steps to follow in Stakeholder Analysis:

• Identify your stakeholders (all people affected by your work, who have influence over it, or who have an interest in its conclusion)
• Determine their involvement, influence, and interest, and document it in the PPM tool; if necessary, create a Responsibility Assignment Matrix (RACI)
• Understand your key stakeholders so you know how they are likely to respond and how you can win their support

Resource Planning and Communication

Resource management involves planning as well as acquiring, developing, and managing employees to optimize project performance. Project team members may have a variety of skill sets and as the project progresses, may be assigned part-time or full-time responsibilities. The PM may also consider resources to add or remove from the team.

Resource management responsibilities include:

• Planning: Identify and document project roles, responsibilities, required skills, and reporting relationships and create a staffing plan
• Acquiring: Confirm resource availability and obtain the team necessary to complete project activities; requests for resources should go through the resource’s manager
• Developing: Improve team member competencies, interactions, and the overall team environment
• Managing: Track team member performance, provide feedback, resolve issues, and manage changes

Change Management and Project Communication Planning

A project communication plan outlines the steps needed to ensure project communications are timely and appropriate, and that there is an approval process and distribution strategy in place. PMs spend much of their time communicating with team members and project stakeholders, whether they are internal or external to the organization. Effective communication creates a bridge between diverse stakeholders who may have different cultural and organizational backgrounds, different levels of expertise, as well as different perspectives and interests.

Sometimes projects are global and enterprise-wide in nature and may impact all associates, in which case it is especially important to create a project communication plan. Project communication plans can also help when a user has a new action, process, or behavior change required as a result of the project work.

Keep the following things in mind when determining whether change management and communications are required for your project work:

Change Characteristics

Change Characteristics include elements of audience scope and impact of the change. This can be defined by criteria such as a region or functional team, or the number of impacted associates. Anything impacting 2,000 or more associates should be considered in combination with the:

• Type of change (simple vs. complex)
• Degree of process and system change expected as part of the project
• Current state of compounded change within the organization

Organizational Attributes

Organizational Attributes include elements that demonstrate change readiness of the total organization. Examples include:

• The perceived need for change among employees and managers or the impact of past changes on employees
• What is the climate of change happening within the organization as an enterprise? Are there very few or many changes happening across the organization?
• How responsive has the organization or targeted audience been of past changes? Has there been reinforcement of change?
• Leadership style and competency in managing change is important. For example, are executive leaders visible and effective with their sponsorship skills? Do managers have the knowledge and skills to lead change and drive adoption?

In general, you should engage IT Communications when the organization attributes assessment and change characteristics assessment for a project present a medium to high risk. Risk assessment tools can be found in the PMO Playbook. A successful communication plan includes all pieces listed below and a successful communication includes those in bold:

• Who (the audience)
• What (key topic/message)
• Why (purpose of message)
• When (frequency and timing of communication)
• How (channel to be used, i.e., the Intranet, email push, digital signage)

IT Communications is a hotspot of activity and requires appropriate lead times to produce communications, gain approvals, and translate if necessary. In general:

• If the audience is small and the criticality is low, 2 weeks’ lead time is acceptable
• If the audience is large and criticality is medium to high, 3-4 weeks’ notice is required
• If the audience for delivery requires access to distribution mailing lists or time to gather email addresses, please allow 3-4 weeks
• If the content requires translation, please allow 3-4 weeks
• For any ALL ASSOCIATE emails, approval is required from Global Corporate Communications and the CEO