Posted on

Project Scope and Business Environment Impact

The project’s business environment can be the most important factor affecting project scope. This impact is agnostic to your project’s development approach (plan driven, agile, hybrid). Each development approach has ways to respond to these changes. It is the project manager’s responsibility along with team leaders, team members, sponsors, and other stakeholders to identify business environment changes early, prepare adequately and adjust to them.

Business Environment Influence on Scope

  1. Business Environment Influence on Scope
  2. What Causes Business Environment Change?
  3. Project Manager Business Environment Changes
  4. Ways to Engage Stakeholders
  5. Tips to Understand the Business Environment Impact

What Causes Business Environment Changes?

As a project leader, it is important to understand the organization’s strategic and operational objectives as well as the specific objectives of the project. It is equally important to understand the external business environment that can impact and introduce change to the project.

Common causes of internal and external business environment change include:

  • Competition / market
  • Regulatory / compliance
  • Technology
  • Politics

A project leader must continuously observe and respond to the business environment. Start by asking good questions. In addition, you must anticipate environmentally caused risks throughout your project.  The following are some strategies for anticipating environmentally caused changes.

Project Manager Business Environment Considerations

There are several actions you can take to sharpen your business environment acumen and prepare for project scope impacts:

Inform Yourself: Expand your organizational knowledge and awareness. Consider the strategic objectives. Who are the key decision makers? What happens if the project fails? What is happening in the industry? Find new influences (e.g. How static is the regulatory or compliance environment?, Will technology change?, Is the competitive landscape changing?). Understand and make connections.

Watch for Changes: Be observant as to what is happening in the marketplace as well as internally in your organization. Look for the ripple effects that can impact your project scope. What is learned?  What is new?

Analyze the Organization: Determine if your organization has the maturity and structures to support environmental changes that may occur during or from the project, how the project can adjust to them and how it can prepare the organization for the change.

Create Processes and Procedures: Look for opportunities to get additional help and support. For example, having a way to identify and escalate a business environment change to appropriate stakeholders is beneficial to dealing with the situation efficiently. By having a clear process it makes it easier for all project stakeholders to escalate concerns.

Monitor the Environment: By monitoring the known environmental factors and our current state we can see trends developing or identify changes to the project environment early to proactively respond during project work.

Identify Obstacles: Explore obstacles as they happen and facilitate ways to help the project more forward.

Continuous Improvement: What are you learning along the way that could help to do better or more efficient work?

Ways to Engage Stakeholders

Ask your stakeholders for assistance in identifying internal and external business environment factors that need to be considered. You’ll want to hear what they think might be influencing the business environment. Ask for their help in evaluating any risks to the project. Encourage stakeholders to help you develop ideas, create processes and evaluation measures to keep the project on track.

Engaging stakeholders is also about sharing relevant project information. For example, you will want to communicate the cost of failing to anticipate business environment changes and impacts to your project. Provide updates on the successes and managing the project within the broader organizational environment. Give your project leadership the right information. Share your reasons for doing this and demonstrate through actions how it’s relevant, appropriate, and important.

Tips to Understand the Business Environment Impact

Here are three tips you can use to evaluate, prepare, and address business environment of your project and be prepared to manage its potential impact on scope.

  1. Clarify the Current State

Clearly define the current state of your business environment. Consider the following to document your understanding:

  • Engage with stakeholders
  • Identify external business environment influencers
  • Don’t forget internal influencers and attitudes
  • Group influencers using an affinity diagram
  • Analyze for missing groups
  • Analyze the impact
  • Prioritize for focus
  1. Create a Register for Business Environment Influencers

Use a register as a repository of the influencers and the relevant data. It should include the name and description of current concerns and include other information. Here is a more detailed list:

  • Name of influencers and a description
  • Category
  • Type (internal / external)
  • Action required
  • Risks
  • Timing
  • Measures
  • Owner
  • Level of influence on project
  1. Perform Check Ups – Did You Get It Right?

As the project work is being done, schedule a periodic re-evaluation of the current state. In this evaluation, review:

  • What is new?
  • What has changed?
  • Could the efforts produce unintended positive or negative results?
  • What should be adjusted?
  • What must be avoided?

RMC’s Got the Support You Need

If you are planning to take the PMP exam, you will need to know about the business environment and the broader impacts that environment has on your projects.  Rita Mulcahy’s Exam Prep materials can help you prepare for this and other exam topics.  We offer PMP Exam Prep instructor-led courses and PMP Exam Prep eLearning. Prep on your own time with Rita’s Exam Prep book, PM FASTrack Exam simulator or our complete PMP Exam Prep System.

If you already have your PMP certification, earn 1 FREE PDU when you listen to our webinar Bursting the Scope Bubble: Business Environment and Its Influence on Your Project.

Posted on

The Project Manager’s Organizational Change Responsibilities

Middle aged project manager at computer working on organizational change

As project manager, you have organizational change responsibilities for the projects you lead.  Your business and strategic role as a project manager requires you to have the knowledge to manage change that originates from your projects.  Knowing how to deal with organization change helps you reduce the impact to existing processes and individual employees while delivering value to your organization.

Successful Change Doesn’t Just Happen – It is Planned

Change is something you encounter in your organization and on your projects. Every project you do, because of its very nature is a temporary endeavor.  The creation of a new product or service involves change.  Organizations change when adapting to market factors including technology, compliance or disruption.  However, it is important to note that successful change is not a given.  Research has shown 70% of major change efforts fail, with only 25% achieving their stated objectives.

As you look at your role as a Project Manager, it is your responsibility to help support organizational changes that result from the projects we lead.  While it is critical to meet the project objectives, as PM you need to look at the deeper influencing factors to understand stakeholder needs, wants, concerns, fears and objections.  As project manager, you also need to understand the market and industry dynamics as well the organization’s culture and its ability to accept change.

People are comfortable with what they know and there is a certain level of resistance to change.  Change can also foster a resistance to additional change. Therefore, as you plan and execute projects, your role as a leader may need to evolve. You may take on the role of a counselor, educator, coach or booster throughout the project.  Shifting roles will help you keep key stakeholders engaged and able to move through the changes resulting from a project.  Consider this list of PM responsibilities as you seek to evolve your role:

  • Identify type of change
  • Evaluate current and future states to understand results required
  • Perform ROI and business case analysis to plan future state and transitions
  • Lead delivery of future state

Business Environment in PMP Exam Content Outline

In 2021, the new PMP Exam content outline changed to 3 domains. The new domains are process, business environment and people. Processes have been a core component of the previous exam content outlines and they are still important, representing 50% of the exam content outline. The reason for this update, according to PMI’s global practice analysis, is to further improve project success and reduce failure as well as address improvements in compliance, quality, efficiencies and business satisfaction.  The ultimate goal is to realize the project benefits and value more consistently.

Within the business environment domain, there are four (4) tasks that outline core responsibilities of project managers of which support organizational change is one. For reference, here is the PMP® Exam Content Outline. These work examples show how the organization influences the project and how your effort as PM includes preparing the organization for the result of the project. The work examples include:

  • Assessing the organizational culture
  • Evaluating the impact of organizational change to project and determine required actions and
  • Evaluating the impact of the project to the organization to determine required actions

So, what are some practical tips to help make your PM change management responsibilities easier?

Tips for PMs to Support Organizational Change

1. Evaluate the organization’s change readiness.

Evaluating your organization’s change readiness is important to measure readiness. Add this assessment during the initiating phase of your project plan alongside the development of your project charter. You can continue to reference and reevaluate it throughout the planning and monitoring of the project.

To start your change readiness analysis, review RMC’s Change Management Readiness Assessment tool.  It is an excellent resource that provides you with suggested questions to assess your organization’s current and future state readiness for change.  You can change, adjust and modify this document for each project.

2. Select the appropriate tools and techniques to analyze.

For the project to succeed, you must help stakeholders understand how their beliefs and actions must adjust in order to deliver the desired results.  And this means their experience will be different after the change. Using a variety of tools and techniques will help in planning and adjusting your projects.

  • Evaluate and identify stakeholder’s experience with the organization’s culture through observation, interviews and document analysis.
  • Understand how stakeholders’ experiences influence their beliefs and actions through focus groups, surveys and root cause analyses.
  • Evaluate and plan for change by asking questions, discussing the proof that a problem exists or the impact of the problem to recommend a solution.

You can represent your findings in your WBS. Include a project management branch that shows the outcomes and artifacts you are creating as deliverables as part of your change assessment and project planning. Then analyze them as part of your risk identification efforts.

3. Develop a planning check list.

A change management checklist helps you identify the specific actions you will take to plan for change. The form can help ask questions to identify why the change is needed, what is the desired result, who will be affected by the change and how will you measure the success of the change.

Want to Learn More?

Interested in building your change management skills? Consider an additional certification such as PMI-ACP or Prosci change management certification. You can also check out our Organizational Change Management webinar recording or our Leading Change eLearning course. Deepen your practical skills to use in your current projects, within your teams and throughout your organization.

Posted on

Contract Issues in Agile Development

Two business people review signing a contract

There has been a significant amount of discussion regarding the tension between development and agile contracts. Many see this conflict as irreconcilable, citing provisions in the Agile Manifesto favoring “working software over comprehensive documentation” and “customer collaboration over contract negotiation.”

Those who see the conflict this way claim that lawyers are operating in an outmoded mindset and need to be educated about the agile method of doing business. These same people claim that lawyers perceive many agile practitioners as unrealistic and naive.

In my view, this so-called tension is the result of a misconception of the lawyer’s role and of his or her duty to the client.

Contracts and Agile Development

  1. The Role of the Lawyer
  2. Implementing the Parties’ Intentions through Form Contracts
  3. Similarities in Agile and Other Development Contracts
  4. Agile-Dependent Provisions
  5. Similarities between Agile and R&D Contracts
  6. What Would an Agile Contract Look Like?

The Role of the Lawyer

The lawyer’s duty is to protect the interests of his or her client. What does that mean, exactly? To those in the “lawyer as dinosaur” camp, it means that a negotiation is perceived as a zero-sum game, with success being defined as winning the maximum number of business points and shifting as much business risk as possible onto the other party. In fairness, I have seen negotiations go that way and, at times, lawyers take a leading role in those types of adversarial negotiations.

In my experience such types of negotiations are ultimately unsuccessful because the relationship and the business objective underlying the agreement usually fail. That doesn’t do anyone any good, and it can’t be viewed as truly protecting the interest of the client.

A lawyer’s job is to assist their client in reaching their business objective. Part of that responsibility includes reducing risk to the client. The definition of risk, however, cannot be compartmentalized into individual business points or contract provisions, and must include the overall goal of the contract.

In the end, the object of the contract is to document the intentions of the parties and to create a mechanism to implement those intentions.

Implementing the Parties’ Intentions through Form Contracts

Much has been written about the need for new and specialized modalities surrounding contracts intended to implement agile methodologies. For example, in 2008 the Norwegian University of Science and Technology conducted a detailed study of problems associated with contracts in agile development projects. This ultimately led the Norwegian Computer Society to adopt a standard form contract to be used for agile software development, maintenance, and service operations.  There are many other form contracts purporting to be agile friendly. For example, see the Draft/Contract for use in DSDM Projects (DSDM refers to dynamic systems development method, an agile methodology).

Although these form contracts can be useful, there are already existing procurement methodologies that can accommodate the iterative approach used in agile software development.

Similarities in Agile and Other Development Contracts

One reason existing form contracts can be used for agile is because agile development shares many of the same needs of other types of development. For starters, you need to identify the parties to the contract. You need to have an effective date and a start date. You need to state when and how the vendor will be paid.

In addition, as with other software contracts, there must be warranties from the vendor, such as one warranting that it owns the rights to the code it will be developing and selling to the purchaser. There should also be some software escrow provision allowing the purchaser to gain access to the code should the vendor file for bankruptcy or go out of business. These are just a couple of examples. There are many others.

Agile-Dependent Provisions

The tricky issue with contracts and agile development stems from the iterative process and the intentional lack of documentation regarding the scope of work or the performance characteristics of the product being purchased.

In a traditional procurement, there is normally a detailed specification or statement of work that sets the standard against which vendor performance will be measured and allows for a firm price. This approach won’t generally work in agile development. But there are other contract methodologies, such as those used in research and development (R&D), designed to deal with situations where detailed specifications are impossible. Such contracts may be adapted to fit into the iterative approach called for by agile.

Similarities between Agile and R&D Contracts

In many agile agreements the requirements, by design, are not well documented. The same can be said for R&D contracts. Parties often enter into R&D contracts without knowing whether the object of the agreement is even doable. One area where these contracts may differ is in the iterative methodology used in agile; however, this is not critical, and the iterative methodology can be documented.

What Would an Agile Contract Look Like?

As far as scope is concerned, both an agile and R&D contract would probably have a simple statement, not necessarily of work, but of goals. There would be provisions allowing for a re-scoping after every iteration, a process for identifying what was done and what was not done. With respect to those items that were not done, the contract would also document a decision process governing whether those pieces of work would be put into the next iteration, mothballed, or discarded. There would probably also be provisions for the re-scoping of work for the next iteration.

Payment would most likely be either on a cost-plus basis (with a fee or profit component) or for time and materials. Given the uncertainties of the project, a firm fixed price would most likely be impossible, but there could be a budget target or cost estimate that might go in at the front end, against which the project progress could be measured.

In this respect, an agile project would differ from R&D in that the end of the project would be defined as when the purchaser runs out of money, not when the goals of the project have been reached. Honestly, this would most likely be extremely dissatisfying to a purchaser, especially one that did not have a business history with the vendor.

There would also need to be provisions governing testing and acceptance, at the end of each iteration and at project completion. One issue is the criteria governing acceptance. If requirements are not defined up front, how do you determine what success looks like at the end? It could be defined by requirements set forth at the beginning of each iteration; the contract would require each successive set of requirements to be met for the project to be deemed successful. With this approach, one concern is the situation where all the pieces work, but the final product is unsatisfactory. In my view this is the largest problem with agile contracts, but in many respects it’s no different than an R&D contract where the parties have goals but no real knowledge of whether those goals can be achieved.

As long as the parties’ expectations regarding the final product are understood and documented up front, with the understanding that if the purchaser’s expectations are not achieved, the purchaser would only have limited recourse, then an agile-based contract would work.

Boilerplate provisions would be similar to those found in other contracts. IP warranties and indemnifications would be the same, as would severability, governing law, notifications, modification, confidentiality, and competition.

RMC is Here to Get You Started

In looking at agile contracts, the documentation requirements are not all that unique and can be fit into other more traditional procurement methodologies. There is no need to completely reinvent the wheel. Rather, the lawyer and practitioner need to keep in mind that they are creating an agreement in an environment of uncertainty, not unlike that found in an R&D contract.

In response to the growing relevance of Agile methodology for all Project Managers, the Project Management Institute (PMI®) has begun offering the Agile Certified Practitioner (PMI-ACP®) certification exam. RMC Project Management offers comprehensive exam preparation products, eLearning and classroom training options to help you earn PMI-ACP certification

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

Posted on

Project Management Approaches and Methodologies

Project manager discusses project approaches and methodologies with team

As a project manager, selecting the right project management approach and methodology is an important step you’ll need to take before starting work on a project. That’s because using the appropriate approach and methodology can make a major difference in the flow of your project and its successful completion.

  1. What is a Project Management Approach?
  2. What Are Popular Project Management Approaches?
  3. How to Select the Right Approach for Your Project
  4. A Hybrid Approach
  5. What Are Common Project Management Methodologies?

What Is a Project Management Approach?

A project management approach defines the overall mindset you have for how to manage the project. Should you plan it traditionally, meaning as completely as possible before you execute, or should you plan and execute the project incrementally? Your project management approach falls along a continuum between plan-based (traditional), and adaptive (incremental). On the other hand, there are many methodologies to choose from. While this might feel overwhelming at first, the nice thing is you can select an approach that best suits each project, and that will help you know what methods to choose. After all, every project is unique, so even though a an approach and methodology might work for one project, it might not for another.

As mentioned, you can use different project management approaches to ensure every project you lead will be a success. To simplify things a bit, we’ve put together overviews of  the most popular types.

1. Agile Project Management

The great thing about taking an agile approach to project management is it provides you with plenty of flexibility. You can change the way you do things as you go to adjust to change, and still keep your project on track.

Rather than following a strict, linear method, this adaptable and collaborative approach makes it easier to implement changes when needed. Therefore, your team may make changes as new learning about the needs of the project requires.

This approach can be helpful if you anticipate a project will need a lot of changes before completion. It’s also beneficial if your stakeholders want to give you frequent feedback as the project progresses.

Pro tip: When you’re ready to learn about how to apply agile principles and methods, RMC is here to help. You can enroll in courses to learn about agile, and we offer exam prep courses that will prepare you to become an Agile Certified Practitioner.

2. Waterfall Project Management

Unlike the agile methodology, waterfall (or traditional project management) provides a more linear,  approach that is less flexible once planning is completed. Basically, your team progresses from one phase to the other as they’re completed.

With this methodology, you rely on more detailed requirements as you move from the start of a project to its end. However, you don’t have the flexibility to make changes after your team starts working without carefully vetting them. For this reason, it’s a good choice when you know how a project needs to go and what the outcome should be.

The stages in this methodology include requirements and analysis, along with design and construction, testing, deployment, and transition to operations. So, if you want to run a project that’s carefully planned with a schedule your team can adhere to, and there’s a clear goal that can be planned in detail with stakeholders , the waterfall method can be a suitable option.

How to Select the Right Approach for Your Project

There are pros and cons associated with each project management approach.  It’s wise to weigh your options and select the method that will be most beneficial to you, your team, and your stakeholders.

A few things to consider as you think about which approach to use:

  • The number of people on your team, and how much guidance they require
  • If a project allows for flexible changes and risks
  • The level of involvement your stakeholders will have
  • The amount of time you have to complete the project
  • The project’s budget, and if it’s fixed or flexible

A Hybrid Approach

Sometimes your project calls for a blended plan driven and agile approach. This technique allows you to select elements of from both methodologies to get the project done.  For example, you use Agile sprints because the scope of your project might not be well defined at the outset of your project.  You create a general project charter to gain approval, which is a plan driven technique.

Therefore, this hybrid approach takes the best of two methodologies and allows you to apply the most appropriate aspects of both.  If you’re interested in how to build the most effective hybrid approach for your project, consider RMC’s Hybrid Agile eLearning Course to guide you through the process.

Once you get to know the various methodologies available, and you begin to try them out in the real world, you’ll become confident in your ability to choose the right one for every project.

What Are Common Project Management Methodologies?

Popular project management methods include:

  • Scrum – An agile methodology characterized by short, fixed production cycles (sprints) with specific goals, that works well with small, skillful and disciplined teams, and uses short, focused meetings.
  • Extreme programming (XP) – A type of agile methodology that’s focused on collaboration.
  • Critical path method – A method that uses a work breakdown structure to map out milestones, commonly used in traditional approaches.

Since agile is considered an instance of Lean thinking, these practices are often integrated into many agile methodologies:

  • Lean – A method of optimizing the way your team works by reducing waste.
  • Kanban – An agile method that uses a visual representation of the phases and steps that need to be completed throughout a project.

Once you get to know the various approaches and  methodologies available, and you begin to try them out in the real world, you’ll become confident in your ability to choose the right one for every project.

Posted on

Project Goals vs Objectives

Close up of business person working at computer on project goals

Project goals and objectives are similar in some ways and different in others. Although both can be used to guide a team through a project, a goal can be viewed as the purpose of the project, while an objective can be used to provide a map for hitting a goal.

To become a more effective project manager, it’s necessary to have a clear understanding of what a goal is versus what an objective is, and how to write and use each of these.

Tips to Understand and Write Project Goals and Objectives

  1. What are Your Objectives?
  2. What are Your Goals?
  3. How to Write Project Objectives and Goals
  4. SMART Objectives and SMART Goals for Project Managers

What Are Your Objectives?

 You can use objectives to clarify the goals of a project before you begin, and you can use them for the duration of a project to keep your team on track toward meeting stakeholder expectations. Also, objectives come in handy when you want to measure progress during a project, as well as when you want to see how well your team performed after the project’s completion.

  • Objectives are specific and measurable, and your team and stakeholders should agree on them.
  • They state what should be achieved by the time the project is complete, including tangible deliverables and they should be realistic.
  • Should be time-constrained and direct your team from start to finish, and they should be kept in mind as you make decisions to keep the project moving in the right direction.

As objectives are met, you should get closer to fulfilling project goals.

Project objectives example: Decrease the number of click-throughs to website so the customer gets to the goal of the link within 1 to 2 clicks.

What Are Your Goals?

While objectives are more specific and short-term, goals are more general and long-term.  Goals are represented in statements that help your team understand what the project has to accomplish for a business. Like objectives, you should be able to measure and track progress on goals to ensure you’re on the path toward meeting them.

  • Goals can be less specific, showcasing what should be possible for a business once a project is completed.
  • They can be centered on resources, deadlines, and performance.
  • Should focus on the long run and the ultimate purpose of the project. Objectives focus on the steps that need to be taken in the short term to reach the goals.

Project goals examples: Increase click-thoughts to website from social media by 15% within three months of release.

How to Write Project Objectives and Goals

It’s best to write your goals and objectives in a way that will be easy to understand. So, rather than using complex terms, stick to plain language and be brief.

Whoever reads your goals and objectives should immediately know what needs to be accomplished by a certain date. Therefore, sticking with action words and numbers is also recommended.

SMART Objectives and Goals for Project Managers

 Whether you’re writing objectives or goals, you can use the SMART method to articulate what you expect to achieve during a project. You can then share these clear expectations with your team so you can work together to get things done.

SMART stands for Specific, Measurable, Achievable, Realistic, and Time-Bound:

  • Specific – Goals and objectives should be defined, so anyone who reads them will understand what’s expected of them. Be clear so your team will know what the preferred outcome is, as well as the individual milestones that need to be met along the way.
  • Measurable – The best way to track progress and see if your team is meeting objectives and goals is by making them measurable. For example, if the goal is to boost sales, set the percentage of increase (e.g. 25%) you’d like to see after the project solution has been implemented.
  • Achievable – Of course, you’ll want your objectives and goals to be attainable, so as you write them, think about whether it’s really possible to achieve them. Take time to consider the steps needed in order to avoid problems like scope creep to ensure success.
  • Realistic – In addition to being achievable, a goal or objective should be realistic. You and your team should have the time, resources, budget, and tools available to make things happen. Expectations shouldn’t be out of reach.
  • Time-Bound – Every goal and objective should have a start date and end date. As you work on a schedule, keep in mind that you might need to wait for one objective to be completed before your team can move on to the next one.

Are You Meeting Your Project Goals and Objectives?

It might take a little practice at first, but once you’re accustomed to writing clear and concise goals and objectives, you will find it easier to manage projects. After establishing these at the start of a project, you’ll be able to refer to them often to see if everything is on track or if changes need to be made.

Sources:

https://thedigitalprojectmanager.com/project-objectives/

https://asana.com/resources/how-project-objectives

https://www.projectmanager.com/blog/how-to-create-smart-goals

https://hubstaff.com/tasks/smart-goals-project-managers

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

Posted on

Project Life Cycle Vs. Development Life Cycle

If you’re new to project management or building your confidence at the mid-level, you’ve likely heard both terms: “Project Life Cycle” and “Development Life Cycle.” Sometimes they get used interchangeably, but make no mistake: these two concepts serve different purposes, involve different stakeholders, and guide different phases of work. Knowing the difference can help you better plan, execute, and communicate on your projects—especially when working across cross-functional teams.

In this guide, we’ll walk through what each life cycle involves, how they relate, and why understanding both is essential to successful delivery.

What Is the Project Life Cycle?

The Project Life Cycle (PLC) represents the high-level phases a project goes through from initiation to closure. Regardless of the industry or methodology used (Waterfall, Agile, hybrid), every project typically follows this structure:

  1. Initiation
  2. Planning
  3. Execution
  4. Monitoring & Controlling
  5. Closure

Let’s look at each stage briefly:

1. Initiation

This is where the project is formally started. It involves:

  • Defining the business need or opportunity
  • Conducting feasibility studies
  • Establishing high-level scope and objectives
  • Securing initial stakeholder approval and funding

Deliverables: Project Charter, Stakeholder Register

2. Planning

Here, the roadmap is built. Planning includes:

  • Defining scope, time, and cost baselines
  • Creating schedules and resource plans
  • Identifying risks and mitigation strategies
  • Establishing communication and quality plans

Deliverables: Project Management Plan, Risk Register, WBS, Gantt Charts

3. Execution

This is where work gets done according to the plan. Key elements:

  • Assigning tasks and managing teams
  • Tracking performance and deliverables
  • Managing stakeholder engagement

Deliverables: Status reports, issue logs, deliverables as per project scope

4. Monitoring & Controlling

This overlaps with execution and includes:

  • Tracking KPIs and progress
  • Managing changes to scope, budget, or timeline
  • Ensuring quality standards are met

Deliverables: Change Requests, Performance Metrics, Quality Reports

5. Closure

The project is wrapped up with:

  • Final deliverables handed off
  • Lessons learned captured
  • Contracts closed
  • Team and stakeholder debriefs

Deliverables: Final Project Report, Lessons Learned Document, Client Sign-off

Key Point: The Project Life Cycle is concerned with managing the project as a whole—not necessarily the specific technical process of building a product or system.

What Is the Development Life Cycle?

The Development Life Cycle (DLC) refers to the process used to design, build, test, and deliver the solution that the project exists to create. It often varies based on what you’re developing:

  • In software development, it’s called the Software Development Life Cycle (SDLC)
  • In product development, it’s the Product Development Life Cycle
  • In construction, you might hear terms like design-build or engineering development cycles

For this blog, we’ll focus primarily on the SDLC model, as it’s the most common use case for project managers working in tech or digital environments.

Common SDLC Phases:

  1. Requirements Gathering & Analysis
  2. Design
  3. Development (or Implementation)
  4. Testing
  5. Deployment
  6. Maintenance

1. Requirements Gathering

This is where the technical team defines what the system needs to do. It involves:

  • Interviews with users and stakeholders
  • Reviewing business processes
  • Documenting functional and non-functional requirements

Deliverables: Requirements Specifications, User Stories

2. Design

The architecture of the system is developed here, including:

  • System models
  • Interface designs
  • Data architecture and technology stacks

Deliverables: Technical Design Documents, Wireframes, ER Diagrams

3. Development

This is the coding or building phase:

  • Developers write and integrate code
  • The design is turned into a working system or application

Deliverables: Source Code, Software Builds

4. Testing

Quality assurance happens here:

  • Functional, performance, and security testing
  • User acceptance testing (UAT)
  • Bug tracking and fixing

Deliverables: Test Plans, Bug Reports, QA Sign-off

5. Deployment

The product goes live:

  • Released to production
  • Go-live planning and stakeholder notifications

Deliverables: Deployment Guides, Release Notes

6. Maintenance

Post-deployment support:

  • Monitoring system performance
  • Handling updates and patches
  • Responding to user feedback and bug reports

Deliverables: Support Logs, Maintenance Reports

Key Point: The Development Life Cycle is focused on building the product or system itself.


So, How Do They Interact?

Here’s where many junior project managers get tripped up: thinking of PLC and DLC as parallel tracks. In reality, the development life cycle lives within the execution phase of the project life cycle.

For example:

  • During Project Planning, you may plan timelines that include each development phase.
  • During Project Execution, the team will follow the development life cycle to build the product.
  • Your Monitoring phase tracks how well the development work is progressing.

A well-managed project ensures that development milestones align with overall project goals, budget, and stakeholder expectations.

Diagram (text format):

Project Life Cycle:
[Initiation] → [Planning] → [Execution] -- [Development Life Cycle] --> [Monitoring] → [Closure]

Common Methodologies and Frameworks

Understanding life cycles also means recognizing the frameworks that structure them.

Project Management Frameworks:

  • PMBOK (Project Management Institute)
  • PRINCE2
  • Agile Project Management (AgilePM)

Development Frameworks:

  • Waterfall
  • Agile (Scrum, Kanban, SAFe)
  • DevOps

A Waterfall project might map development and project stages linearly, while an Agile team might iterate through development cycles within a broader project timeline.

Agile Note: In Agile, the concept of a linear “Project Life Cycle” can blur. Instead of one big initiation-planning-execution cycle, you may run sprints or releases that loop through mini life cycles of planning, developing, testing, and delivering.

Why This Matters to Junior and Mid-Level PMs

  1. Better Stakeholder Communication When you can distinguish between project stages and development stages, you can more clearly explain timelines and dependencies to both business and technical stakeholders.
  2. Improved Planning Accuracy Understanding the development life cycle helps you plan execution activities with greater precision, especially when working with engineering or IT teams.
  3. Smarter Risk Management Knowing how and when system design or testing fits into the broader project helps you anticipate delays, resource bottlenecks, and integration risks.
  4. Stronger Change Control Changes in requirements can impact development differently than project schedules. Understanding both life cycles helps you evaluate change impacts more thoroughly.
  5. Career Growth The ability to speak both “project” and “development” fluently sets you apart. It positions you as someone who can bridge business goals and technical delivery.

Final Thoughts: Bridging Two Worlds

The Project Life Cycle is your roadmap for managing the work. The Development Life Cycle is your blueprint for building the solution.

As a junior or mid-level project manager, you don’t need to be a developer or architect—but you do need to understand how their work fits into the bigger picture. The more comfortable you are with both life cycles, the more effective you’ll be in coordinating teams, meeting deadlines, and delivering results that matter.

Key Takeaways:

  • PLC = Managing the overall project
  • DLC = Building the solution within the project
  • Development activities live inside the Execution phase of a project
  • Aligning the two life cycles helps avoid surprises, rework, and miscommunication

Mastering the distinction doesn’t just improve your PM skills—it sharpens your leadership edge. Stay curious, stay clear, and always know which life cycle you’re in.

Posted on

Strategic Planning: Project Managers & Business Analysts

Project manager working on strategic plan with team

Strategic planning isn’t just for the C-suite. For project managers (PMs) and business analysts (BAs), it’s a shared mindset—and when done well, a powerful collaborative edge. It’s what separates reactive task-jugglers from proactive leaders who shape business outcomes.

Too often, strategic planning is treated like a once-a-year offsite agenda item. But in project environments, it’s a daily discipline. Project managers and business analysts bring complementary strengths to the table—and when they plan strategically together, the results ripple across the organization.

Let’s explore how PMs and BAs can lean into strategy, together.

Where Strategy Starts: Shared Understanding

Strategic planning begins with clarity: What are we solving? Who are we solving it for? Why does it matter?

  • BAs shine here. They dig into business needs, ask the right questions, and define the problem space.
  • PMs turn that understanding into structure—schedules, budgets, risk assessments, and delivery plans.

When this early collaboration happens, it prevents teams from building elegant solutions to the wrong problems.

Tip: Start planning sessions with shared ownership of goals. Don’t just delegate requirements to the BA or logistics to the PM. Map the business case together.

Aligning Tactics to Strategy

Strategic planning isn’t abstract. It’s about making smart decisions with finite resources. PMs and BAs each bring a lens to these decisions:

  • PMs focus on feasibility and execution: Can we realistically deliver this on time and on budget?
  • BAs focus on value: Is this the right thing to deliver?

Both are essential. Without feasibility, strategy fails. Without value, delivery is irrelevant.

Think of the PM as managing the “how” and the BA as refining the “what.” Planning together ensures both are right.

Strategic Planning Throughout the Project

Planning isn’t a single moment; it’s an ongoing process.

During Initiation:

  • BAs clarify the problem, analyze stakeholders, and shape the vision.
  • PMs define scope, build timelines, and start risk assessments.

Together, they align on what success looks like.

During Execution:

  • PMs adjust plans based on progress, blockers, and change requests.
  • BAs validate that the solution still meets evolving business needs.

Together, they pivot smartly—without losing sight of strategy.

During Closure:

  • PMs capture lessons learned and close out deliverables.
  • BAs assess business value and post-launch outcomes.

Together, they inform future strategic decisions.

Strategic Tools for PM & BA Collaboration

Some tools that support strategic co-planning:

  • Business Case Canvas: Aligns goals, metrics, and solution fit
  • RACI Matrix: Clarifies who does what in strategy and planning
  • Product Roadmaps: Connect features to business priorities
  • SWOT or PESTLE Analysis: Contextualizes planning in wider trends
  • Backlog Prioritization: Ensures tactical choices reflect strategic needs

Use these together—not in silos. Strategy is a team sport.

The Human Side of Strategic Planning

This isn’t just about frameworks. It’s about relationship. The best project managers and business analysts:

  • Respect each other’s expertise
  • Share accountability, not blame
  • Stay curious and challenge assumptions

PMs can lean on BAs to deepen stakeholder insight and spot unseen dependencies. BAs can lean on PMs to translate vision into action and keep momentum focused.

One powerful habit: Do joint stakeholder walkthroughs. Hearing the same thing together often reveals misalignment faster than emails or handoffs.

Final Thought: Strategy Is a Shared Language

Project managers and business analysts are most powerful when they plan strategically together—not in parallel, but in partnership. In today’s pace of change, strategy isn’t static. It’s iterative, evolving, and rooted in insight. By combining delivery discipline with analytical clarity, PMs and BAs make strategy real. That’s not just good planning. That’s good business.

Key Takeaways:

  • Strategic planning is ongoing and collaborative
  • PMs and BAs bring different but complementary strengths
  • Aligning early prevents rework and delivers higher value
  • Shared tools and shared mindset create alignment
  • The strongest strategies come from shared understanding and trust

Let strategy be more than a slide deck. Let it be how you work, together.

Posted on

Project Manager Career Path: What to Expect

Female professional consider a project manager career path

A project management career is an exciting profession that presents opportunities to continually learn and grow. To help figure out if it’s the right path for you, read on to learn more about career path options, industry choices and salary expectations.

Project Manager Career Path

  1. Is Project Management a Good Career?
  2. Are There Multiple Project Management Careers to Choose From?
  3. What Are Some of the Industries You Can Work in as a Project Manager?
  4. Are Project Managers Paid Well?
  5. How Do You Become a Project Manager?

Is Project Management a Good Career?

One of the most attractive things about project management is that it’s a fast-growing career path. And there aren’t enough people to fill all the project management roles that various businesses are hiring for all over the world. This may translate to higher earnings if you’re able to use your skills to land a position in a competitive market.

So, if you want to start a job where growth is possible, and where there will be plenty of demand for people with your skill set, this might be the ideal choice.

Is project management a dead-end job?

Absolutely not! When you’re a project manager, you can move up from an entry level position to an executive level position. This means you’ll have the chance to acquire more skills, more recognition, and a higher salary.

This isn’t a career path that limits your potential, so you can decide if you want to stay in the same position or if you need to make a change.

Are There Multiple Project Management Careers to Choose From?

When it comes to project management, we’re talking about a variety of roles in a wide range of industries. There are so many options available, so you can decide which path to take to fulfill your aspirations.

What is the project manager career path?

As you make your way from a lower-level position to a higher level one, you can take on different titles and perform various tasks that will prove your worth in the workplace.

Here’s an example of just one path you can consider taking to build your career:

Some people start out as project coordinators or assistant project managers to get the chance to work on a project while supporting the project manager and their team. This can help you get a feel for what it’s like leading a team and accomplishing milestones.

After acquiring enough experience, you may be ready to become a project manager. But you don’t need to stop there. After proving yourself, you might be able to move up to the senior project manager role. This typically involves overseeing even bigger teams of professionals or multiple smaller teams, so you can focus on more than one project at once.

What is the program manager career path?

Before becoming a program manager, you usually need to work as a project manager for several years to become a pro at running projects. This background will give you the know-how and confidence to tackle multiple related projects simultaneously.

When you take this path, you can also become a portfolio manager, which entails directing and overseeing a portfolio of programs and projects. And you can move even higher up in an organization by becoming a project management office (PMO) director, who leads—you guessed it—a company’s project management office.

What Are Some of the Industries You Can Work in as a Project Manager?

Project managers work in just about every industry. This means you can pursue a particular industry that you love, or you can switch between different industries to keep things interesting and challenge yourself in new ways. Common examples include:

  • Health Insurance
  • IT
  • Construction
  • Financial Services
  • Manufacturing

One thing to keep in mind is that each industry will require its own unique skills and education beyond what you need to know for general project management. Browse job descriptions to see what they typically expect, such as college degrees or expertise in a particular area (e.g. building permits and codes for a career in construction).

While salaries vary based on factors like your education and experience level, as well as where you’re working, one thing is true: project managers can be paid very well.

How much do project managers and program managers make?

  • A project manager might earn, on average, $80,000 to $116,000 annually.
  • A program manager might earn, on average, around $125,000 annually.
  • The median salary for a project manager in the IT industry is around $142,000 annually.
  • The median salary for a project manager in the construction industry is around $93,000 annually.

How Do You Become a Project Manager?

In addition to a college education, you can also enter the field of project management by getting a certification from the Project Management Institute (PMI).

To get started, you can become a Certified Associate in Project Management (CAPM). But if you really want to be recognized by employers, getting your Project Management Professional (PMP) certification is a smart move.

Whichever path you choose, if you’re ready to learn what it takes to become certified and dive into this career, our courses and exam prep programs can help pave the way. Check them out and contact us if you have any questions.

Sources:

https://www.northeastern.edu/graduate/blog/project-management-career-path/

https://www.flexjobs.com/blog/post/project-management-career-paths/

Posted on

Project Management Compliance

Woman at computer reviewing project management compliance

To be effective, every leader needs to have an understanding of different types of compliance.  Compliance is important because organizations and projects need to conform to internal and external rules governing a project. In the PMP Exam context, compliance is part of the business environment domain. If you work in an industry where compliance impacts your work or you just want more information on types of compliance and their benefits, read on.

Compliance in Project Management

  1. Types and Examples of Compliance
  2. Benefits of Compliance on Projects

Types and Examples of Compliance

As a project leader you are responsible for managing compliance for your projects.  One way to do this is to create compliance categories to organize and manage project compliance.  We typically look at four compliance categories:  Mandatory, Discretionary, Internal, and External. Let’s take a closer look at each category.

External

Compliance can be external.  For example, the applicable laws, rules and regulations imposed by federal, state and local governments need compliance.  Failure to do so can result in civil and/or criminal liability for the organization and even personal liability for the project manager.  Needless to say, failure to comply with such rules could also result in the complete failure of the project.

Environmental regulations are one example of an external rule that must be complied with.  If you are running a project for the construction of a bridge and the plan calls for the filling of wetlands, you will have to get the necessary permits before you can start work.  If you start, before obtaining those permits, it is likely that your project will be stopped cold and significant fines and other penalties will be imposed on your company.

Internal

There may also be internal rules that need compliance.  An example of internal rules would be company rules around procurement of outside resources.  The company might require you to follow a bidding or proposal process.

If you fail to do so, and hand a contract off to a school friend, you may not find yourself facing criminal liability, but you certainly would have a very good chance suffering consequences from within the company.

Mandatory

There are compliance requirements that must be conformed to that are absolute.  The example of the fill permit described above is one of example. There are all sorts of these requirements.  Some are obvious in the project context, some are not.

It is the non-obvious ones that you need to watch out for.

A simple example is that as a project manager, you can’t take company equipment and convert it for you own use. That is theft and is fairly obvious. A less obvious violation would be where a project manager takes resources from one project and uses them for another. This could be a violation of internal rules governing project budgeting. It also could be a violation of external regulations imposed on a firm by a granting agency. If the firm doing the project is the recipient of a grant they may be required to account to a state or federal agency for the use of grant money.

Discretionary

Discretionary compliance requirements are those that might be considered best practices. Failure to conform to these requirements will not necessarily result in liability of civil or criminal consequences.  An example of a discretionary compliance requirement would be guidelines.  A guideline might represent a best practice that saves time and money within a particular business environment and the failure to follow that guideline might result in the project being delayed, coming in above budget or could result in project failure.

There are numerous situations where project managers are criticized or even fired for failing to follow corporate guidelines for project performance. An example of this would be where a company has a guideline for preparation of a risk management plan and an identified best practice for creating that plan.  If that guideline is not followed by the project manager certain risks might not being identified. The failure to follow the guideline will not result in civil or criminal liability but there could be adverse consequences for the project and/or the project manager.

Benefits of Compliance on Projects

Compliance touches on a broad range of project management processes. As seen above, compliance can deal with preparing the risk management plan. It’s also obvious that compliance has the potential of impacting communication management, stakeholder engagement and scope.

Indeed, because compliance issues define the business and project environment, they have the potential of impacting every aspect of the project in some way.  For this reason, compliance must be managed as part of the project.

To learn more about compliance, check out RMC’s free recorded webinar entitled Focus on Compliance: Expand Your Awareness and Improve Project Success.

Sources:

https://ccbjournal.com/articles/use-project-management-approach-compliance-programs

https://project-management-knowledge.com/definitions/c/compliance/

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

Posted on

Project Management Compliance Process

Woman working on project management compliance process

Many years ago, I had neighbors who owned and operated a B&B. They had a barn on their property which burned to the ground. Instead of replacing the barn, they decided to build a large conference space that included a commercial kitchen and the ability to seat over 100 guests. The plan was to hold conferences and weddings. They got their building permits and off they went. The project could have benefitted from a project management compliance process.

Unfortunately, they never checked the local zoning ordinance. While they were permitted to operate a B&B at their location and serve incidental meals to their guests, they were not allowed to hold conferences or host wedding receptions. The code allowed them to build the facility but not operate it. Had they done their research, perhaps contacted the town, they could have saved themselves a lot of money.

Compliance is important, some would say of paramount importance, since if a project is not in compliance it would most likely fail or at least incur significant cost and delay.

Clearly a project needs to be in compliance. It is the environment in which the project operates.  There should be a project management compliance process for every project. This process can be simple or extensive, depending on the size and complexity of the project as well as the project environment. The process touches on many aspects of project management, including risk, requirements, stakeholder engagement, planning and many others. Let’s start with compliance requirements.

Compliance Process in Project Management

  1. Compliance Requirements
  2. The Project Management Compliance Process Checklist
  3. Engaging Stakeholders
  4. Tips to Improve Compliance

Compliance Requirements

Gathering compliance requirements is similar to gathering requirements in other aspects of the project. A project manager should engage internal and external resources.

Associations and Affiliations

External organizations can have information and provide recommendations and standards that could provide compliance guidance, best practices and standards.  If your firm is a member of one of these organizations, and even if they are not, the organization may be willing to help by providing advice or even assistance. Examples of organizations could be Underwriter’s Laboratories or even the Internal Revenue Service.

Compliance Tool Kits

Open-source software or documents and guides could be a valuable resource or tool kits for compliance.  Examples could be health and safety, risk or quality guides or a business rules engine.

Consultants

Lawyers and accountants come to mind in helping a project manager to shape and understand their compliance environment.  Business and financial consultants can also prove to be valuable resources as well.

The Project Management Compliance Process Checklist

Gathering compliance requirements is only the first step. A project manager now needs to create a process for compliance to be followed throughout the project. The project manager also needs to be mindful of the fact that many compliance requirements change over time and that this could occur during the life of the project. Any project management compliance process must:

  1. Inform the project manager of laws and regulations.
  2. Require the project manager or a member of the project team or an outside expert to periodically check for and communicate changes to the compliance environment.
  3. Determine whether the organization has the maturity and structures in place to maintain compliance.
  4. Ensure that any process created involves interested or necessary stakeholders.
  5. The process must identify obstacles to compliance.
  6. Finally, the compliance process must continuously improve.

Engaging Stakeholders

A stakeholder is anyone who has an interest in the outcome of a project. This is a pretty wide net you are casting. In addition to including customers or others who might benefit from the product resulting from your project, it could also include members within the organization who could be adversely affected by your projects failure to be in compliance.

Stakeholders can be a valuable resource in identifying compliance issues.  The project manager can find out where they encounter issues or roadblocks.  They may also provide valuable insights into compliance solutions or even suggest polices or practices that could streamline compliance.

Of course, a project manager must exercise common sense when engaging stakeholders. Some projects require a degree of secrecy and under the broad definition or stakeholder, such broad disclosure could endanger that secrecy.  As examples, I’m thinking business transactions or the creation of a new product. Over engagement could result in disclosure of proprietary information.

Tips to Improve Compliance

In addition to engaging stakeholders and identifying compliance requirements, here are a few tools you can use to help you categorize your compliance requirements:

1. Affinity Diagram

This is an organization tool to help you manage compliance.  You can group compliance into categories such as security, systems or regulatory.  This should allow for more efficient management.

2. Identify Missing Groups

Work with stakeholders when reviewing affiliate diagrams to see if anything or anyone is left out.

3. Engage with Specialists

At the end of the day, call someone that knows more about this than you do. As a project manager, you’re not expected to be an expert, in law, accounting or HIPPA compliance. If these issues arise call someone who knows more about this stuff than you do.

4. Create a Compliance Register

This is a project document that allows you to track and share compliance information. The register could include a compliance requirement name and number and describes the compliance requirement. The description should include the category, type of compliance issue and what needs to be done within the project to deal with it.

There can be a cross reference to the risk register if the compliance issue presents threats or opportunities as well as plans for dealing with them. Who is going to respond to the issue as well as what needs to be done?

RMC’s Compliance Expertise

Your efforts in managing compliance can result in you identifying gaps in your knowledge and shortfalls. We suggest that you create a repository to capture what you know about compliance that can be used by others in your organization.

If you find that there are significant gaps in your abilities to manage compliance, RMC is here to help. View RMC’s webinar Focus on Compliance: Expand Your Awareness and Improve Project Success to expand your knowledge of compliance.

Compliance is part of the Business Environment Domain on the PMP Exam. If you are preparing for the PMP exam, you should expect questions about it. RMC expert in preparing you to take and pass the exam. Check our PMP exam prep class schedule.

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]