Articles Archives - Page 6 of 460 - Project Management Articles, Webinars, Templates and Jobs

Dealing with Arrogant Clients

Written by Patrick Mwangi on June 8, 2024. Posted in Articles.

The clients, being our employers and the key financiers in projects, tend to be insidious at certain times. This is very common during the project conception phase, when the project planning is in motion. As the experienced consultant, I am sure that you had your fair share of dealings and agree that not all of them are cooperative.

Firstly, achieving the milestone of being a consultant is not an easy task. There should be no room for negotiations for such `kind` charges, as you worked hard for that specific reward. Secondly, you are the party with the required information and advice. You bear the responsibility and never bend to demands outside the professional order of practice. That being said, I assume that, as the consultant, you best gauge your client from the briefing stage. If the situation is erratic, abandon the mission with immediate effect. Feeling sorry for the client and being desperate for a project will mess up your career.

It’s also safe to note that clients are often insecure about their finances, especially the sole financiers. This is mainly because there are untrustworthy consultants we hear of every day or who meet with the wrong advisors prior to your counsel. For instance, foremen are known to tell clients that consultants ask for `unnecessary` sums of money and are therefore inconvenient to approach. This messes up the psychology of the client, who ends up concluding that the consultant is the fraud in his plans. This is the precursor to animosity between the client and consultants.

In my practice, I choose to settle on two very clear strategies. Firstly, restrict the authority of the client only to the briefing. Don’t give the client too much power because, as you know, you are first protecting him against himself. Let him speak his mind and ideas as he narrates the house of his dreams, but not tell you how to do your work afterwards! This is the cardinal rule of management. Apart from financing and briefing, the direct influence of the client on the project should be limited.

The young professionals are terrified of such procedures because they fear losing clients because they will miss out on being part of the project, and obviously because of the petty sums offered. Never fear losing the client; it’s part of the job. You dare charge unworthy sums; you are also an accomplice in undermining the integrity of your relevant professional designation. Furthermore, most clients are usually aware that projects are capital-intensive investments and come prepared. The cries and stubbornness you experience are just mind games to salvage as many discounts as possible. It’s not real.

Advertisement
[widget id=”custom_html-68″]

Secondly, embrace the use of contracts to legitimize some of your agreements. The first item here is payments, followed by quality assurance. Where payments are not in lump sums, always demand 60% of your defined sum in advance, especially for project managers. I also recommend you put in writing all site visit costs agreed upon as well as any other necessary allowances. You are also to agree that the quality of work is not to be interfered with in any way because, in case of building failures, the consultant is held responsible. Such interference may result from the misinformation supplied by the foreman regarding reducing the quantity of materials or substituting the designed quality altogether. There may also be future inflation in materials.

Having these agreements in writing helps to ensure that the client remains disciplined regardless of the situation. This will be a win-win event. Remember, this is an agreement between the client and consultant or contractor, where necessary, and must be signed in the presence of a witness of common consideration from both sides.

Dearest client, I am the professional who has the information you require. Kindly listen and adhere to my advice and instructions. It is for your own good. I cannot invent information out of the bushes. I have repeatedly mastered the skill for several years for me to dedicate it to you. Therefore, let me do my work responsibly with no unnecessary interference, as you reward me with what I deserve.

How to Prevent Project Burnout Before It Strikes

Written by Adrian Reed on June 8, 2024. Posted in Articles.

I suspect many people reading this work on projects pretty continuously. It’s normal to jump from one project straight to the next, often without much time for reflection and decompression. In fact, you might be balancing multiple smaller projects at the same time. That’s a hard gig: typically each project has its own set of deadlines, and Project A’s sponsor doesn’t care that Project B has suddenly put extra demands on your time…

In situations like this, it’s easy to get into the vicious cycle of working longer and longer hours. Sometimes, for a very short and defined period of time, this might be OK. But when it becomes the norm, it can become unhealthy. When weekends become the ‘mop up’ time for all the emails you couldn’t clear during the week, and Monday is filled with a sense of dread, something is probably wrong. If you’re there at the moment, I feel for you. I’ve been there. I suspect we’ve all been there.

In this blog, I wanted to share some tips that can help avoid situations like this. Of course, we are all individuals and we all have different working patterns, so what works for me might not work for you. Certainly, you’ll want to adapt the tips below, but hopefully they’ll provide you with a useful starting point:

Say “No” Effectively

There is rarely a lack of work to be done, there is a lack of time and attention to do it effectively. Say “yes” to unrealistic deadlines and there’s a risk that everything will be rushed and everything will be late.

Yet saying “no” sounds career-limiting, doesn’t it? Who would dare say “no” to a senior leader? Perhaps it’s all about how the message is given. For example:

Say “yes, and here’s the impact”: Imagine you’re stretched and another task comes in. A way of responding might be to say: “I can absolutely do that, by that date. However, this will impact tasks B and C. Are you happy for this new task to take priority?”.
Say “Thanks for thinking of me, let me introduce you to someone that can help”: It’s easy to inadvertently take on the work that others might be able to do more effectively. Perhaps someone is asking you to pick up a support issue on a project that launched months ago and is now in ‘Business as Usual’ (BAU). A response might be “Thanks, it’s always really interesting to hear how things are going on that system! I’m somewhat out of the loop with that now, as the support team took over. It’s really important that these issues are logged with them, so they can track trends. Shall I send you over a link to the defect logging form? If you don’t get any response, feel free to follow up with me and I’ll connect you with my contact there”.
Say “No, but here’s what I can do (and offer options)”: Imagine a completely unrealistic deadline has been given. Saying yes will save short term pain, but will cause long term issues when the deadline is missed. A better option may be to say “I can’t hit that deadline (for the following reasons), however here’s an estimate of what can be done. Alternatively, with additional resource we could achieve this…”
Finally, a flat out “no” is fine sometimes: Not everyone agrees with this, but in my view, particularly when something is optional, it’s fine to say a flat out no. “Would you like to help organize the summer BBQ?”. “No thanks, I’ve got a lot on right now, so that’s not something I’m interested in”. Of course, this needs to be delivered with rapport, empathy and respect.

There are many other ways, and it’s important to be aware of context and culture. What works in one situation will not work in others.

Advertisement
[widget id=”custom_html-68″]

Find Ways of Recharging (And Make Time For Them)

We all have things that replenish our energy. For me, it’s exercise (whether that’s walking or going to the gym), reading and other hobbies. It will be different for you. The irony is that when things get hectic, often these are the very things that we jettison. Don’t! Build them into your routine and make them non-negotiable.

Celebrate Successes

It’s so easy to jump from sprint to sprint, delivery to delivery without actually reflecting on what was achieved. Celebrating even small successes is worthwhile. This doesn’t have to be a major event, just a lunch with the team, or some other kind of social event can help mark the milestone.

Watch for Warning Signs

Finally, it’s important that we all look out for warning signs—in ourselves and others. I remember friend and fellow BA Times author Christina Lovelock talking about ‘digital distress signals’. Is someone emailing at 6am and then again at 10pm? Might that be an indication that they are overwhelmed? If the person has an unusual work pattern (perhaps working before the kids go to school, and catching up in the evening) it might be totally fine. But if this isn’t the case, they might be pulling 14 hour days, and that’s got to be impacting them.

We all feel and experience overwhelm differently, and a little bit of stress is not unusual. There’s even a theory that a little bit of stress is good for you. But continuous stress is an issue, and it’s worth watching out for.

Of course, this article has only scratched the surface of this topic, but I hope you’ve found the ideas thought-provoking. I’d love to hear how you avoid burnout on projects. Be sure to connect with me on LinkedIn and let’s keep the conversation going!

The Value of a Project Charter

Written by Lauren Zinsmeister on June 1, 2024. Posted in Articles.

If you’re familiar with the Project Management Book of Knowledge, or PMBOK for short, you know all about the Project Charter and its criticality to the success of a project. The PMBOK says that the project cannot start until the Project Sponsor formally signs off on the Charter.

Having worked at midsize companies for nearly 15 years, I learned that actual Project Charters with formal sign-off are more of a “big company” thing. To date, I haven’t once been required to write a Charter or get one approved to begin a project. Let me tell you why I insist on a Charter and have more than just the Project Sponsor sign off before I kick off a project. Come with me on this thought journey.

If I had to pick a single area of knowledge from the PMBOK as the most critical, I would pick Stakeholder Management. You can have the best plan and the best tools, but a tumultuous stakeholder situation can completely derail a project. On the flip side, you can have a scrappy team with few processes and subpar tools, but with committed people working well together, a project can succeed in spite of other project elements being challenging.

If I had to pick an area of knowledge to be second most critical, it would be Time Management. This encompasses your ability to scope the project, break it down into tasks, understand dependencies, build a project schedule, and keep the team aligned with each other as well as the schedule. In a sense, it’s a superset of a few other areas and captures the core of your project plan.

Enter the Project Charter, which I would argue is the most critical project artifact. Below are the basic elements of a good Project Charter:

Problem statement
Business case
Goal statement
Timeline
Scope
Team members

Diving into these 6 elements, we see 1, 2, 3, and 6 align to Stakeholder Management and 4 and 5 align to Time Management.

Advertisement
[widget id=”custom_html-68″]

Let’s start by looking at the Stakeholder Management elements.

Problem statement – Having this clearly written in the Charter ensures that key stakeholders agree a problem exists. They are agreeing on what that problem is. Finally, they are agreeing that this project is the right approach to solving the problem.
Business case – Here is where stakeholders are agreeing that this project is worth the resources. It’s possible to have everyone agree that a problem exists and needs to be solved, but it’s something entirely different to agree on its priority and resourcing.
Goal statement – Different people can look at the same problem and come to a different conclusion about how to solve it. Articulating the goal in writing will avoid assumptions and make it clear to stakeholders what everyone is working toward. Without stakeholder alignment on the project goal, the project is doomed to become tumultuous when the project team inevitably encounters a fork in the road.
Team members – We’ve agreed we have a problem to solve, we’ve agreed it’s worth investing in, and we’ve agreed on what the ultimate goal looks like. This section gets specific about whose time will need to be invested, what the commitment is, and what their responsibilities will be. Key stakeholders reviewing the Charter will be able to think through the impact on their teams and make sure they are able to commit the team members required. They will also be able to identify other team members who may not be listed, helping to complete the project team.

Our remaining two elements are tied to Time Management, though agreement on these is also inextricably tied to Stakeholder Management.

Timeline – To be able to write this section of the Charter, you will have had to do some high level project scoping and establish your project structure. Do you have phases? Stagger starts? Is your execution stage planned to be managed using Agile methodology, so the timeline needs to be flexible? All of those considerations and more are required for a timeline estimate. Putting this estimate in front of key stakeholders in the Charter ensures they understand the high level of time commitment. This provides an opportunity for discussion if some stakeholders think it needs to be completed faster or someone says they can’t commit the required resources for the deadline, so the project needs to be extended.
Scope – They say the devil is in the details, and this is where those details live. Clarity on scope allows for work estimates, project scheduling, and work coordination among team members. Clarity on out-of-scope work is just as important, because that enables you to define “done,” wrap up the project when in-scope deliverables are complete, and hand off deliverables and/or processes to business-as-usual owners for long-term ownership. The clearer you can be about your scope in the Charter, the fewer struggles you’ll have with scope creep later.

I personally expand on these base elements with a couple of my own tried-and-true tools. Seizing the opportunity to get stakeholder alignment, I also include the below:

Communication plan – I use this section to detail what information will be shared with which stakeholders as well as the method I will use. This is especially important if some team members or stakeholders are in different time zones, and even more important if there are people from multiple cultures. Communication norms vary in different cultures, so I like to ensure everyone knows what to expect and has an opportunity to raise a hand if they need something different from what I had originally planned.
Project change management – What are the criteria for something to be considered a project change? What process does it go through to be approved? Who has the authority to approve a change? Stakeholder alignment up front will save time and struggle when someone wants to add a deliverable to the project or expand the project to include related work that is discovered during project execution.

The Project Charter provides the best opportunity for you to detail critical components of your project and get stakeholder alignment. You can’t possibly list every detail, but you can align on your plans, processes, and expectations so everyone is working in the same way when questions and challenges inevitably arise.

That One Project You Aren’t Sure You’ll Survive…

Written by Paul Gouws on May 28, 2024. Posted in Articles.

We all had that one project—the one that made us question our career choices, doubt our sanity, and consider a swift exit from the world of project management. It took me a moment to recall mine. The late nights, the endless meetings, and the creeping feeling that I was steering a ship into a storm without a compass. Yes, that project—the one that left me pondering whether I had accidentally signed up for a one-way ticket to project manager purgatory.

But here is the twist: I survived. And not just survived—I emerged wiser, battle-tested, and armed with insights that no textbook or certification could provide.

So, why am I sharing this? Because somewhere out there, another project manager is teetering on the edge, contemplating surrender. Maybe, just maybe, my journey can offer a glimmer of hope—a lifeline to keep them afloat.

Lessons from the Trenches

What follows are my personal revelations from years ago, working on that one project we all know. I am not advising or guiding here; I am merely sharing my experience throughout the life cycle of the project. You might share similar experiences or see something completely new. Luckily, the project world has evolved over the years, but nothing can match up to the real project experience. Hard-won tricks, battle-tested strategies, and yes, confronting the dreaded burnout head-on.

The Burnout: A Dangerous Undertow

Now, let us delve into the next chapter of my journey—the one where burnout took center stage. It was not merely a buzzword; it functioned as a silent assassin. Picture this: nights devoid of sleep, days fuelled by caffeine, and a to-do list that multiplied faster than rabbits in spring. I had been there, but I was fortunate to be surrounded by top talent, including a mentor who guided me throughout. Together, we navigated the treacherous waters of that one project, skillfully avoiding the siren call of burnout.

As a naturally spirited individual, I have always approached life with unwavering positivity. To me, there existed nothing on this earth that could not be rectified, no challenge too daunting, and no issue too tangled to unravel. I excel at solving problems, whether they are complex or simple—until one day, I hit a wall. Wait, was I failing at something? Impossible. I resolved to try harder next time, right? But two weeks later, another failure. It dawned on me—I was caught in a loop, akin to a sales pitch endlessly replayed during an infomercial:

Are you perpetually failing on a project?
Are you working extra hours and days to evade failure?
Are you feeling utterly worthless?

These symptoms became my daily companions. I would gather myself overnight, only to wake up to the same emotional hangover the next day. I soldiered on, convinced that this was normal and that I would eventually power through. But stress insidiously crept in—I smoked more, drank more, and hoped it would all magically vanish. The harsh truth? It did not. Burnout was lurking, and I did not even recognize it until it had me in its grip six months down the line.

Burnout does not announce itself with fanfare. It tiptoes in, whispering exhaustion into your bones. And I, the sprinter—the one who thrives on daily victories—was suddenly running a marathon. You see, there are sprinters and marathoners in the project management world. Sprinters excel in short bursts, while marathoners maintain a steady pace over the long haul. Me? I was a sprinter on a six-year project. Sure, you can break down a colossal project into smaller goals, but it is not sustainable. The sprinter craves daily wins, not a development cycle that spans years. The funny thing is, I only realized that I had burned out after the burnout had already taken its toll, which could be six months down the line. The crucial lesson? Recognize burnout while it is happening, not after the fact.

Below were the three fundamental areas that I needed to improve on to survive:

The first thing I did was to start exercising; even if you just run for a bit, it needs to be for a minimum of 40 minutes at least. If you are in the habit of exercising, just check that you are not swapping out your exercise time for work. There will always be work, so making time for exercising will not cause any harm.
Watch full-on action movies with a lot happening in them at full volume.
Replace bad coping mechanisms with healthy ones.

Strategic Funding Approach for Ambiguous Requirements

In the realm of project management, grappling with vague requirements is a familiar challenge. When faced with this uncertainty, consider a strategic funding strategy that not only brings clarity but also optimizes your company’s resources.

Phase-Specific Funding

Rather than seeking the entire project budget upfront, focus on securing funds exclusively for the requirements phase. By doing so, you establish a clear boundary for the initial work.

Once the requirements phase is successfully completed, you can confidently request additional project funds. This approach minimizes financial risk and aligns funding with tangible progress.

Yes, I did hear we are following agile, agile, agile, and we will request funds as we go. It is all good… Please add all the funds that you have spent so far and link them to what has been delivered. I will stop there.

We followed a hybrid approach here, waterfall the requirements, and then you can follow any framework or methodology you prefer for the rest of the phases. We monitored a few aspects of the budget continuously:

Approved Budget – How much money did the company approve for the project or phase?
YTD actuals spend – How much money have you spent already to date?
YTD planned spend – How much money are you planning on spending for the remainder of the project?
Quality Check Spend – How much money did you spend, according to the finance team?
Variance – How much money will you have left at the end of the project?

Oh, and on a side note, do not think you will be called a hero if your budget ends up in a big positive, that is a sign of poor planning. We worked on a 5% variance either way to be good, and I thought it was fair.

Poor Planning: The Quicksand of Project Execution

Let us discuss the BRS—the unsung hero of projects. BRS stands for Business Requirements Specification—a fusion of the BRD (Business Requirement Document) and the BSS (Business Specification Spec). Think of it as the Rosetta Stone that translated business needs into design blueprints. We hired Business System Analysts instead of your run-of-the-mill Business Analysts (BAs) to save on funds. The BSA crafted an all-in-one document, weaving requirements and designs into a seamless tapestry. We did encounter scope creep where the business would sneak in extra requirements, citing the “we missed it at the start” clause.

Armed with the BRS, we generated work packages—bite-sized tasks that our team could chew on. It was like breaking a colossal chocolate bar into manageable squares.

We tracked the progress of each BRS in the war room (you will hear about this later) with a card like this:

Advertisement
[widget id=”custom_html-68″]

Development Without Design

Imagine constructing a house without blueprints. Initiating development without clear designs or requirements documents is akin to erecting a skyscraper on shaky ground. It is a recipe for chaos. With the solutions architect on your right and the business analyst on your left, create the as-is and to-be designs, with the plan in the middle—it is that straightforward. The solutions architect must advise you on any risks that might arise as you progress on your project journey, while the business analyst must keep you laser-focused on the customers’ requirements.

Untamed Timelines

Committing to timelines without consulting your team is like setting sail without checking the weather forecast. A big no-no. Involve all stakeholders, assess risks, and adjust your course accordingly. I am not talking about adding a buffer based on your experiences; I am just saying that if you are not a developer, then do not put estimates down for a new website to be built; ask the expert.

The War Room: Where Strategy Meets Unity

The term “war room” conjures images of battle-hardened generals huddled over maps, plotting tactical maneuvers to outwit the enemy. But in the context of this project, it is less about combat and more about collaboration. Allow me to demystify the war room—a sacred space where ideas clash, plans take shape, and unity prevails.

As a die-hard team player, I thrive in the war room’s charged atmosphere. Why? Because it compels us to gather, discuss, and align. Team meetings become our compass, pointing us toward shared goals. Unity emerges—the kind that transcends job titles and department silos. We are no longer lone warriors; we are a battalion with a common mission.

Picture it: four walls, each adorned with a whiteboard. This is your canvas. Now, let us map out the headings—the battle plans—inspired by the V-Model of testing:

Low/High-level Designs: The blueprints. Architects, developers, and UX designers converge. We sketch, iterate, and breathe life into concepts.
System/Business Requirements: Here, we decode the client’s vision. What problem are we solving? What outcomes matter? These requirements anchor our journey.
Development: Our troops mobilize. Timelines, milestones, and resource allocation take shape. It is the heartbeat of execution.
PDT/AIT/SIT/UAT: The litmus test. Testing engineers scrutinize, validate, and ensure our creation stands tall.

Sounds straightforward, right? But remember, the war room is not just about strategy—it is about camaraderie, resilience, and the art of turning chaos into cohesion. In the maze of project management, requirement cards served as our guiding leads. But these are not ordinary cards—they are color-coded keys to complexity, dependencies, and progress.

We created these cards to help us keep track of how each item is progressing. Each of the cards will represent a specific requirement, and each card will have the following on it:

Traceability number – Once you have completed your designs and have them up in your war room, you will be able to number every change required to the design. That number will be inserted in this block so that you have traceability between the requirements and the design. This card is only for business requirements, not interface requirements; there is a different card for interfaces. This means that when you walk into the war room, you can easily spot what part of the system you are touching and where it is based on the design.
Dependency number – Some items are codependent. They need each other to thrive. This box holds the magic number—the item that must precede another. Dependencies, untangled.
Phases from left to right – BRS, DEV, SIT, UAT, DEPLOYED. depending on which team currently owns this ticket, the indicator will move from BRS to DEV or to whichever stage it is in now: same ticket, different owners… We were busy with a custom version of Kan Ban, or whichever version you prefer… Survival was the key word here.

Something like this:

Card Color System –

Red Card The crimson flag. These cards represent the most complex items—the uncharted territories. None of your team members have ventured here, and their experience is limited. Brace for challenges.
Amber Card: The caution signs. These items have been glimpsed by 1 or 2 resources. Familiar, but not routine. Approach with vigilance.
Green Card: The Oasis. These cards signify easy items—your team has danced this tango before. They have mastered it and executed it multiple times. Smooth sailing ahead.

Remember, this card is exclusively for business requirements. Interface requirements have their own dance floor. Keep them separate, like parallel universes.

So, when you step into the war room, eyes scanning the system’s blueprint, these cards whisper: “Here is where you tread; here is where you leap.

Development (Crazy Stream)

Where Requirements Take Shape

The Quest for Requirements: Picture it—a developer picks a ticket and vanishes into the coding abyss, only to reappear days later, battle-worn and seeking aid. Sound familiar? We have all danced this tango. But fear not; we devised a remedy.
The Senior-Junior Alliance: We paired senior developers with their junior counterparts. Mentorship duets. It eased some challenges, but yes, development time took a hit. Still, the defect rate waned, and after three months, we found our rhythm.
Scope Creep and the Unseen Impact: Alas, scope management is our Achilles’ heel. Product owners, blissfully unaware, kept adding tweaks. “This button’s off,” they would say. “That field’s too snug.” The result? A deluge of tickets drowned our team.
The Cricket Field Strategy: Desperation breeds innovation. So, we turned to cricket. A whiteboard became our field. Each developer chose their cricket idols. The rules? For every ticket completed, a run is scored. But for every defect found, a wicket fell. Morning stand-ups played out on our “cricket field.” The results? Astounding. Quality soared, spirits soared, and our team hit sixes daily.

The Peer Review Revolution

Passing the Baton: As soon as a developer finished, they would pass the baton—the code—to the next in line. Peer reviews ensued. Quality improved, and knowledge flowed. It was our secret weapon against mediocrity.

User Acceptance Testing

More than halfway through the project, we decided to permanently move key users into the project team permanently. This ended up being the right call. As it was a complex project, by the time we got to user acceptance testing, the users permanently assigned to the project could act as super users in the UAT environment and did assist greatly with fast-tracking any testing that needed to be done. We would also assign a business analyst and a developer to each UAT session to resolve any questions or concerns on the spot.

The second value added to assigning permanent business users to the project for the duration is that they are part of the team, and they will fight for the project in other business forums. We did have a big gap between the project team and business when we started, but this move changed it really into a positive.

On a big, complex project, it is easy to get stuck in the testing cycle due to the business aiming for a bug-free system. There is not one single application that is bug/defect-free; if there is one that you know of, they are not sharing it with you. Coach or guide the business users to log defects but also prioritize them based on financial, reputational, and legal impact. Well, this is what we used. Low-level cosmetic bugs should not stop you from going live. Get a product out by fixing all the high and medium defects, and once live, the low defects can be fixed. But it’s super important to get something out. These days, they call it an MVP (Minimum viable product); we just call it and get it into production so that we can start making a difference.

The Operational Handover post went live.

Like the UAT team, it worked best for us to include one or two operational resources permanently on the project, as they would end up supporting the product once it was live. They also assisted in documenting all the information in the operational handover document. You will not be so lucky to do this on all the projects, but at least put it in place on strategic projects.

I trust the above will give you motivation to continue your project management journey and never give up.

VMO Or PMO: How To Choose One for your Org

Written by Alankar Karpe on May 28, 2024. Posted in Articles.

Defining PMO and VMO

A project management office (PMO) is a group, or functional unit, that sets, maintains, and enforces the practices, policies, and standards for structuring and executing projects within an organization.

According to the Project Management Institute (PMI), a PMO is essential for enterprises seeking to centralize and coordinate the management of projects throughout their life cycles.

The Value Management Office (VMO) is an organizational function responsible for facilitating the Lean Portfolio Management process and for fostering operational excellence and lean governance as part of a Lean-Agile transformation.

Value management office (VMO) is an agile inspired function which came into existence after the focus shifted from project outcomes to Value creation. Traditionally PMO are aimed at completion of projects within triple constraints. But what if they fail to add any significant value to the organization? The shift from PMO to VMO is a shift in focus from managing projects to maximizing value across the organization.

Establishing a Value Management Office is an outcome focused which enables agility by leveraging small and easy controls. It is focused more on individuals and their interactions to generate value delivered to customers in the quickest time as compared to PMO which is more process driven and not the quickest of the lot.

Value Management Office (VMO):

Focus on Value Realization: The primary focus of a VMO is to ensure that the organization maximizes the value it receives from its investments, initiatives, and projects. It is concerned with the strategic alignment and value delivery of projects and programs.
Strategic Alignment: VMOs work closely with senior leadership to align projects and initiatives with the organization’s strategic objectives. They prioritize projects that contribute the most to achieving strategic goals.
Benefits Management: VMOs are responsible for defining, tracking, and realizing the expected benefits and value from projects and programs. They establish key performance indicators (KPIs) to measure value delivery.
Risk Management: VMOs assess and manage risks related to value delivery, ensuring that projects are on track to achieve their intended benefits and making adjustments as necessary.
Portfolio Management: VMOs often oversee the entire project and program portfolio, ensuring that resources are allocated to initiatives that provide the greatest value. They may also make decisions about project funding and continuation.

Project Management Office (PMO):

Focus on Project Execution: PMOs primarily focus on the successful planning, execution, and delivery of projects. They ensure that projects are completed on time, within budget, and according to scope.
Project Methodology: PMOs establish and enforce project management methodologies, standards, and best practices within the organization. They provide guidance and tools to project managers.
Resource Management: PMOs are responsible for resource allocation and capacity planning, ensuring that the right people with the right skills are assigned to projects.
Project Governance: PMOs oversee project governance, including project initiation, risk management, issue resolution, and project reporting. They ensure compliance with project management standards.
Project Documentation: PMOs maintain project documentation, including project plans, schedules, budgets, and status reports. They often facilitate project reviews and lessons learned sessions.

Advertisement
[widget id=”custom_html-68″]

VMO or PMO?

Here are some of the factors which affect the organization to choose between PMO or VMO.

- Maturity of project management
- Primary objective of the organization
- Overall authority of the PM
- Strategic alignment of the project

Here are some key considerations to help your organization to choose between a PMO to VMO:

Understand the key differences between a PMO and a VMO: A PMO focuses on managing projects and ensuring they are delivered on time, within budget, and to scope. A VMO, on the other hand, focuses on maximizing value across the organization by aligning projects and initiatives with the overall business strategy.
Align your VMO with the organization’s strategy: To maximize value, a VMO has to be aligned with the organization’s overall strategy. This requires a deep understanding of the organization’s goals and objectives, as well as an understanding of how each project or an initiative contributes to those goals. On the other hand, PMO sometimes does not goes into that strategic level, instead it achieves the goal of successful completion of project within the triple constraint.
Develop a value framework: A value framework is a set of criteria used to assess the value of projects and initiatives. It can include factors such as ROI, strategic alignment, risk, and stakeholder satisfaction. Developing a value framework will help ensure that the VMO is focused on maximizing value across the organization.
Communicate the value of the VMO: Transitioning from a PMO to a VMO requires buy-in from stakeholders across the organization. It’s important to communicate the value which a VMO can bring and how it will help the organization achieve its goals. Since VMO operates on the strategic level, stakeholders’ involvement and their buy ins is very high.
Build a team with the right skills: The skills required for a VMO are different from those required for a PMO. A VMO requires people with strong business acumen, strategic thinking skills, and the ability to influence and communicate effectively. Make sure to build a team with the right set of skills to support the transition.
Focus on continuous improvement: A VMO is not a static entity, and it requires continuous improvement to maximize value. Regularly review and refine the value framework, assess the effectiveness of the VMO, and look for ways to improve processes and procedures

The purpose of PMO and VMO are different, but organizations can choose to function with one or both depending on their needs, maturity and their overall objectives.

References:

https://scaledagileframework.com/blog/glossary_term/agile-program-management-office/
The Rise of Value Management Office (pwc.com)
https://agilemanagementoffice.com/value-management-office-vs-project-management-office-whats-the-difference/
https://scottambler.com/what-i-do/presentation-from-pmo-to-value-management-offices/
https://www.projectmanagement.com/webinars/799732/transforming-the-pmo-into-a-vmo–value-management-office
https://www.pmsolutions.com/articles/Project_Management_2022_Research_Report.pdf

About the Authors:

Girish Devapura, PMP, CSM, Prince 2, SAFe 6 Agilist works as Associate Practice Partner and Cloud Transformation Program Manager with Wipro, India. He is an Engineer and working as IT professional with Practice Management, People Management, Program Management and Delivery Management experience of more than 22 years.

Alankar Karpe, PMP, PMI-ACP, SAFe 6 Agilist has 20+ years of experience in Program and project management, Strategic management, Business consulting & research. He is working with Wipro, India as a Program Manager in Bangalore, India. He has a postgraduate diploma in management and Master certificate in Business analysis from George Washington University.

References:

https://www.pmsolutions.com/articles/Project_Management_2022_Research_Report.pdf