Skip to main content

Tag: Methodologies

PMTimes_Jun25_2024

Agile – Autonomy & Self-Organization

In one of our coaching workshops, we were discussing what makes an Agile coach successful. We had a good discussion on this topic, and we came up with two concepts: autonomy and self-organization, which seem slightly similar, but they are mostly used interchangeably.

So first, let’s see what these terms talk about.

[Note: These are very vast topics for discussion; we cannot conclude this in a few lines of writing; I have only highlighted them briefly here in this article.]

 

Autonomy: The cultural steps toward empowerment

Agile development relies more on people, their mindset, and their culture than on processes.

Leadership,

Collaboration,

Informal communication,

Flexible and participative,

Encouraging, cooperative

Are other characteristics of agile software development.

 

Many organizations are embracing agile ways of working in an attempt to build faster, more customer-focused organizations. They are redesigning themselves to create a culture where decision-making is transitioned away from middle management towards those working with customers on the front lines, i.e., teams.

Ultimately, they seek engagement in order to create a culture where the team is more empowered to truly delight customers. Autonomy is the critical ingredient for this change.

Autonomy is always implemented through leaders. Leaders should have thought that employees should get well engaged with the organization, and if Leaders really want a high standard of engagement, they have to look for self-direction, empowerment, and a and a little bit of control from employees over what they have to do—their task, over when they have to do—their time, over who they have to do with—their team, and over how they have to do their technique.

If organizations and leaders think about these aspects, then employees will surely do things better.

 

Autonomy is not where leaders or bosses tell employees exactly what to do and precisely how to do it; Leaders take away all employee choices of any kind and largely control what they should do; and Employees are compliant with leaders and follow their instructions without digging up their own thoughts and experiences. This is very bad, controlling, and hijacking the working relationship between employees and their leaders.

However, autonomy is often misunderstood as power.

Autonomy should not be confused with the need for power, which is entirely a different matter and one that some employees will avoid at all costs. The difference between power and autonomy can be summed up as follows: Power is the desire to control not just one’s own actions but the actions of others, while autonomy is concerned with the ability to operate independently.

(more control and less autonomy)

 

Self-Organization: The Desire to be self-managed and self-driven

At its simplest level, a self-organizing team is one that does not depend on or wait for a manager to assign work. Instead, these teams find their own work and manage the associated responsibilities and timelines; they do require a mentor who can help grow their skills.

 

Defining self-organizing teams

A group of motivated individuals who work together toward a goal have the ability and authority to take decisions and readily adapt to changing demands. Let’s look at some important ingredients for a self-organizing team:

  • They pull work for themselves and don’t wait for their managers to assign work. This ensures a greater sense of ownership and commitment.
  • They manage their work (allocation, reallocation, estimation, delivery, and rework) as a group.
  • They still require mentoring and coaching, but they don’t require “command and control.”
  • They communicate more with each other, and their commitments are more often to project teams than to the Scrum Master.
  • They continuously enhance their own skills and recommend innovative ideas and improvements.

 

Five essentials of self-organizing teams

  • Competency: Individuals need to be competent for the job at hand. This will result in confidence in their work and eliminate the need for direction from above.
  • Collaboration: They should work as a team rather than as a group of individuals. Teamwork is encouraged.
  • Motivation: Team motivation is the key to success. Team members should be focused and interested in their work.
  • Trust and respect: Team members trust and respect each other. They believe in collective code ownership and are ready to go the extra mile to help each other resolve issues.
  • Continuity: The team should be together for a reasonable duration; changing its composition every now and then doesn’t help. Continuity is essential for the team.

 

Creating a self-organizing team

A common criticism of self-organizing teams is, “We cannot just put eight random individuals together, tell them to self-organize, and expect anything good to result.”

Creating a self-organizing team can be considered a three-step process.

Training: Proper classroom training can help satisfy many of the principles that self-organizing teams require. Specifically, hard skills training is needed to make each employee competent in a particular domain or technology. Soft skills training is also helpful.

Coaching: Once the team starts working together, adopt a coaching style to see if the members are facing any difficulties. They may require more support and guidance at the beginning. Some indicators of a self-organizing team are: scrum ceremonies, team enjoyment of the work, and teams pulling tasks for themselves.

By the end of this phase, you will know the team is self-organizing. However, keep your eyes open to observe the team’s behavior and provide need-based coaching.

 

Mentoring: Once a team starts self-organizing, the journey has only just begun. Team members still require mentoring to grow their skills and maintain the balance of the team. This mentoring should also help with continuity by ensuring everyone grows together and remains motivated. As mentioned earlier, a self-organizing team doesn’t need “command and control,” but it does need coaching and mentoring.

Teams are not always static; they change over time, but the frequency matters. Building a self-organizing team is an on-going process. Whenever a team’s composition changes, we need to repeat the whole team-building lifecycle (forming, storming, norming, and performing).

 

Advertisement
[widget id=”custom_html-68″]

 

How can we relate these two concepts?

Autonomy and self-management are two different concepts, but they are starting to be used interchangeably, as I said before.

Okay, to set up the stage, let’s see from 30,000 feet and consider, for now, these terms as

Autonomy is at the top management level, whereas self-organization is at the team level.

 

In self-organized teams,

  • There are no managers. Everything is self-directed and self-driven.
  • There is no one to set goals; teams decide their own learning path.
  • In self-organizing, a team sets their destination, sets accountability for the tasks, and decides how to reach the destination.
  • How many tasks, how often they have to do them, how many hours they have to do—it’s totally up to the team.

Autonomy, on the other hand, is different.

  • Autonomy means that there is someone who sets strategic direction and the goal for the employee [let’s call that someone a leader or top management], but the employee has the freedom to decide how to achieve the given goal.
  • Managers are there to guide, provide feedback, and advise employees, but they will not watch over the employee’s shoulder every step of the way.
  • There is always someone to review you, give you feedback, and promote you.
  • In autonomy, the team themselves decides and is accountable for how to reach the destination. But the destination is not set by the team; it is set by someone.

 

 

 

1A: Micromanagement Culture: no high-level purpose; just shut up and follow orders. The team is also not mature enough, and the manager takes almost all the decisions. Teams are management-compliant. Management always says we are here to decide what is good for you; you just follow what we are saying. This is leading to poor performance.

1B: In a large organization, autonomy is a tricky balancing act. For example, suppose you have hired a junior developer. First, they will need training, direction, and coaching. Then, over time, they will become more skilled and experienced. And then they will understand the company’s business model. As this happens, you can trust them with larger pieces of work and with less supervision.

Teams are similar in this quadrant. They aren’t all ready for autonomy right away, where team maturity is low, which again leads to poor performance.

2A: This quadrant exactly talks oppositely to 1B. So leaders are good at communicating what problems need to be solved, but they are also good at telling teams how to solve them. However, teams are well mature and self-organized; they know how to approach the given goal; this level of autonomy leads to dissatisfaction and a loss of motivation in teams.

 

2B: High autonomy with higher team maturity means leaders focus on what problems to solve and let the teams figure out how to solve them. This culture always brings continuous improvement and a healthy working environment.

Autonomy is the biggest factor when people decide to leave their current place of employment. Often, employees will stay in a position even if the salary is low, so long as they maintain some level of control over how they perform their work. Autonomy provides employees with a sense of collective ownership; they have organizational citizenship and, thus, a sense of belonging.

Yes, autonomy plays a critical role in reshaping our workplaces, but don’t forget to balance autonomy with self-organization for better results.

Even if at the organization level, leaders promote autonomy culture, it does not mean at the team level we achieved self-organization immediately. There are certain stages (mentioned above) that lead to self-organizing and performing teams for better results.

 

Studies found that in many organizations, there is a lack of system for team support, and reduced external autonomy is an important barrier to introducing self-organizing teams. These findings have implications for software development managers and practitioners.

Still, the process of designing, supporting, and coaching agile teams is not adequately addressed and understood in the context of software development organizations.

Further, there is a need for new knowledge on how companies should organize for the right level of autonomy and utilize self-organized agile teams to attain better performance, productivity, innovation, and value creation, and thus increase competitiveness.

 

 

Follows:

-Jacob Morgan

-Daniel Pink

https://www.planview.com/resources/articles/what-is-self-organizing-team/

PMTimes_Jun12_2024

Mastering Project Management – 5 Powerful Techniques for Project Managers

In the real world of project management, success hinges on the adept application of techniques and methodologies that facilitate efficient planning, execution, and delivery. Whether overseeing a small team or orchestrating complex, multi-faceted projects, project managers must leverage a diverse toolkit of strategies to navigate challenges and achieve objectives effectively. Here are five powerful techniques that project managers can harness to excel in their roles and drive project success.

 

1. Effective Communication and Stakeholder Engagement

At the heart of successful project management lies effective communication and stakeholder engagement. Project managers must establish clear lines of communication with team members, stakeholders, and clients to ensure alignment of expectations, goals, and deliverables. Regular meetings, status updates, and progress reports facilitate transparency and collaboration, fostering a shared understanding of project requirements and priorities.

Moreover, proactive stakeholder engagement is crucial for managing expectations, soliciting feedback, and resolving conflicts or issues promptly. By cultivating strong relationships with stakeholders and maintaining open channels of communication, project managers can mitigate risks, build trust, and garner support for project initiatives.

 

2. Strategic Planning and Risk Management

Strategic planning forms the bedrock of successful project execution. Project managers must develop comprehensive project plans that outline objectives, scope, timelines, resources, and milestones. A well-defined project plan serves as a roadmap for the entire project team, providing clarity on roles, responsibilities, and deliverables.

Furthermore, effective risk management is essential for identifying, assessing, and mitigating potential risks that could impede project progress. Project managers should conduct risk assessments regularly, anticipate potential obstacles, and implement contingency plans to address unforeseen challenges. By proactively managing risks, project managers can minimize disruptions and keep projects on track.

 

3. Agile Methodologies and Adaptive Leadership

In today’s dynamic business environment, flexibility and adaptability are paramount. Agile methodologies such as Scrum and Kanban offer a flexible approach to project management, emphasizing iterative development, continuous improvement, and customer collaboration. Project managers can leverage Agile principles to respond swiftly to changing requirements, prioritize deliverables, and deliver value incrementally.

Moreover, adaptive leadership is essential for guiding teams through uncertainty and ambiguity. Project managers must possess the ability to pivot quickly, make informed decisions, and inspire confidence in their teams. By fostering a culture of adaptability and innovation, project managers can empower their teams to embrace change and drive continuous improvement.

 

Advertisement
[widget id=”custom_html-68″]

 

4. Resource Optimization and Conflict Resolution

Effective resource management is critical for optimizing project performance and maximizing efficiency. Project managers must allocate resources judiciously, balancing workload, skills, and availability to ensure optimal utilization of resources. By aligning resource allocations with project priorities and objectives, project managers can minimize bottlenecks, streamline workflows, and enhance productivity.

Additionally, adept conflict resolution skills are indispensable for resolving disputes, managing interpersonal conflicts, and maintaining team cohesion. Project managers must address conflicts promptly, objectively, and constructively, fostering a collaborative and harmonious work environment. By facilitating open communication and mutual respect among team members, project managers can mitigate conflict and promote a positive team dynamic.

 

5. Continuous Improvement and Lessons Learned

Continuous improvement is a hallmark of successful project management. Project managers should conduct regular retrospectives and post-project reviews to evaluate performance, identify lessons learned, and implement process improvements. By soliciting feedback from team members, stakeholders, and clients, project managers can glean valuable insights into areas for enhancement and refinement.

Moreover, embracing a culture of continuous learning and professional development is essential for staying abreast of emerging trends, best practices, and industry standards. Project managers should invest in ongoing training, certifications, and knowledge-sharing initiatives to expand their skill sets and enhance their effectiveness as leaders.

 

Conclusion

In the dynamic and fast-paced world of project management, mastering these five powerful techniques is essential for driving project success. By prioritizing effective communication, strategic planning, Agile methodologies, resource optimization, and continuous improvement, project managers can navigate challenges, inspire their teams, and deliver exceptional results. With a steadfast commitment to excellence and continuous learning, project managers can elevate their performance and lead their teams to triumph in any project endeavor.


References

Adams, John, and Bryan Campbell. 1982. Roles and Responsibilities of the Project Manager. Drexel Hill, PA: Project Management Institute PMI
Cavendish, Penny, and Martin Martin. 1982. Negotiating & Contracting for Project Management. Drexel Hill, PA: Project Management Institute PMI
James P. Lewis. 2007. Mastering Project Management: Applying Advanced Concepts to Systems Thinking, Control & Evaluation, Resource Allocation, McGraw Hill; 2 edition
Cathy Lake.1998. Mastering Project Management. Thorogood Publishing; Illustrated edition
PMTimes_Jun8_2024

Dealing with Arrogant Clients

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.

PMTimes_May28_2024

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

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.

PMTimes_May28_2024

VMO Or PMO: How To Choose One for your Org

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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:
  1. https://scaledagileframework.com/blog/glossary_term/agile-program-management-office/
  2. The Rise of Value Management Office (pwc.com)
  3. https://agilemanagementoffice.com/value-management-office-vs-project-management-office-whats-the-difference/
  4. https://scottambler.com/what-i-do/presentation-from-pmo-to-value-management-offices/
  5. https://www.projectmanagement.com/webinars/799732/transforming-the-pmo-into-a-vmo–value-management-office
  6. 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.