Skip to main content

Tag: Project Management

PMTimes_Jun14_2023

Project Management for Midsize Companies

Written by Lauren Zinsmeister on . Posted in Articles.

In many ways, Project Management is more art than science. Those of us who have spent years in the field have most likely studied the science of it through classes and certifications.

There are certainly best practices that apply most of the time and a Project Manager would do well to have that foundation. But dare I say, the majority of textbook concepts don’t apply much of the time? Let me share a story of a project I tried to manage “by the book” that taught me a big lesson about adapting the “book” to the needs of the company and the team.

During one of my early roles as a Project Manager I worked hard to be organized and apply all the concepts I learned while studying for my Project Management Professional (PMP) certification. I remember one project in particular where I meticulously developed a Work Breakdown Structure (WBS) and calculated the critical path. I had a Microsoft Project sheet a mile long, as this was a major project that would take more than a year to complete. All my details were in order. Project Schedule – check.

Confident in my plan, I brought the project team together. I had worked with key stakeholders to identify all the departments involved in the project and worked with those department leads to know which people should represent their department. I shared my project documents with the team and talked through roles and responsibilities. Stakeholder Management – check.

I knew part of my job was to clear roadblocks for the team, which included the roadblocks of me being a bottleneck. I thought the best way to keep everyone informed was to democratize project documents and have teams make their updates directly rather than funnel all updates through me. I created automations to remind team representatives to make weekly updates.

I had automations to notify people when one of their predecessor items was updated so they would know right away. I had automations to notify both me and team representatives when an update was overdue. Everyone had access to view, so no one ever had to wait on me to share a document or give a status update. We had weekly status meetings to allow for discussion and broader visibility, as well as ad hoc meetings for specific topics as they arose. Transparency and Collaboration – check.

 

Advertisement
[widget id=”custom_html-68″]

 

If you haven’t already guessed, let me tell you how this worked out. Not a single person ever went into the project tracker to make an update. Not a single person ever went into the project tracker to see status. My first pivot was to start collecting updates weekly and input them into the tracker myself. This allowed me to stay closer to the project details and gave me an opportunity to do a weekly assessment of project health with more context.

Those weekly conversations turned out to be so much more valuable than independent updates in the tracker. Every week, I would take this updated tracker and the deeper context I had to give a status update. I would share my screen and show the tracker so everyone could see visually where we were compared to the overall plan.

If you haven’t already guessed, let me tell you why this failed fast. If every team was meeting with me weekly to give me an update, why did they need to sit through a weekly status meeting of me telling them where their items were in the project? They didn’t. I lost the team’s engagement fast. My next pivot was a change that has stuck with me through the years. I did the legwork to meet with teams, understand their status, challenges, dependencies, needs, and projections. I consolidated all the information and culled it to down to what was critical.

Every Monday I sent an email with the week’s game plan, including all work expected to be done with deadlines and names of people responsible for doing the work. Every Friday I sent an email as a Reply All giving an update on what had been completed as expected, what had changed, what was delayed and why. If something meaningful changed and needed discussion or a decision, I would schedule a meeting to discuss it. We now had emails for things that could be emails, and meetings for things that needed to be discussed live.

This raised my credibility with the team when I called a meeting, because they trusted that there was something meeting-worthy to discuss rather than just a status update that could and should be an email instead. My Monday “game plan” emails served as an easy reference for project team members to know exactly what they needed to work on, which increased the rate of project work completion because there was more clarity and it was easily accessible.

Nearly 10 years later, I still rely on this approach. My Monday and Friday templates have evolved as my projects have changed, but this approach has proven successful time and again.

This semi-informal approach to Project Management would likely not succeed at a company with tens of thousands of employees. With larger teams and greater numbers of stakeholders, proper project management tools and formal project communication methods are likely necessary. On the other end of the spectrum, this semi-formal Project Management with meticulous planning and centralized tracking is probably more than is needed at a small company.

When teams are small and work closely together, it’s much easier for everyone to know what everyone is working on without a person dedicated to keeping it all organized. My time at midsize companies has helped me find this Goldilocks approach somewhere in the middle.

PMTimes_Jun06_2023

Shu-Ha-Ri and Servant Leadership

Written by Lawrence Dong on . Posted in Articles.

In today’s rapidly evolving IT landscape, leadership styles play a pivotal role in shaping the culture and success of companies. With unique challenges and demands, it is crucial for leaders to adopt effective approaches that resonate with the modern workforce. Among many leadership styles, there are two prominent styles within IT companies – servant leadership and dictator leadership. Each leadership style has different implications for IT project delivery and for the delivery leads and/or project managers.

 

What is Dictator Leadership

Dictator (or dictatorship) leadership, despite its negative connotations, can be effective in specific situations (e.g., where discipline and obedience are absolutely necessary). This style involves a more autocratic approach, with leaders making independent decisions and providing clear directives to the team. IT delivery leads may adopt dictatorship leadership during high-pressure scenarios or when immediate action is required. However, it is crucial to balance this style with open communication channels and involving the team in decision-making whenever possible.

 

What is Servant Leadership

Servant leadership is a people-centered approach that prioritises empowering and serving the needs of the team. IT delivery leads following this style foster collaboration, open communication, and trust-building within the organisation. Creating an inclusive work environment, providing resources and support for team members to excel and offering coaching opportunities are key elements of servant leadership.

 

What is Shu-Ha-Ri

Shu-Ha-Ri is a concept that originates from the Japanese martial art Aikido. Aikido master Endo Seishiro explains the concept via the following statement:

“It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.”

Shu-Ha-Ri is increasingly popular with companies where Agile methodology influences their project delivery ways of working.

 

Advertisement
[widget id=”custom_html-68″]

 

How Shu-Hai-Ri Complements Servant Leadership

In the “Shu-Ha-Ri” framework, the servant leader guides the team closely at the beginning (Shu), transitions to a more hands-off approach (Ha), and ultimately reaches the stage where team members can make decisions independently while aligning with the organisational vision (Ri).

Example of Servant Leadership with Shu-Ha-Ri: Estimation

 

Shu: A delivery lead provides a pre-defined method of user story estimation, and the newly launched Agile development team follow the method in their first month.

Ha: In the second month, the Agile development team members reach out to the deliver lead to learn other estimation methods. They then decide to use a different estimation method under the guidance of the delivery lead.

Ri: Six months later, Agile development team members review all estimation methods and choose another fit-for-purpose estimation method all by themselves, without involvement of the delivery lead.

 

Playbook of Shu-Ha-Ri

 

Conclusion

Effective leadership in modern IT companies requires an understanding of different leadership styles and the ability to adapt to specific situations. IT delivery leads must navigate the complex challenges of the industry, drive success and inspire their teams to achieve their fullest potential. By adopting a fit-for-purpose leadership style based on the context, IT delivery leads can create a positive and productive work environment that fosters innovation, engagement and continuous growth. The concept of “Shu-Ha-Ri” provides a “test case” for leadership development and allows leaders to evolve alongside their teams.

 

 

Reference:
  1. Wikipedia, “Shu-Ha-Ri”, https://en.wikipedia.org/wiki/Shuhari
  2. Brian Tait, “Traditional Leadership Vs. Servant Leadership”, https://www.forbes.com/sites/forbescoachescouncil/2020/03/11/traditional-leadership-vs-servant-leadership/
PMTimes_May31_2023

Beyond Traditional Metrics: Why Adaptive KPIs are the Future of Project Management

Written by Paul Oppong on . Posted in Articles.

In a recent engagement with a government client, I came across an intriguing yet common conundrum regarding the enforcement of KPIs. Individual projects within their diverse portfolio were flagged ‘red’, signalling they were off course, yet the overall portfolio surprisingly reflected a ‘green’ status, implying smooth operations. This stark inconsistency, compounded by disagreements over the statuses of individual projects, underlined the critical need for a more sophisticated, adaptive approach to KPIs in project management.

Introduction

Conventional KPIs in the realm of project management often bear resemblance to religious texts – unwavering and unchanging, even in the face of shifting project dynamics. This rigid constancy, while providing a sense of stability, may distort perceptions of project performance and overlook potential avenues for improvement. In this article, we delve deeper into these inherent limitations of traditional KPIs and champion a more agile, adaptive approach, one that aligns better with the fluid and ever evolving and unique nature of today’s project landscapes.

Let’s scrutinize the limitations of traditional KPIs. These conventional metrics, while offering a valuable framework, do exhibit certain drawbacks. They possess an inflexible character, condense the complexities of project statuses into a simplistic ‘traffic light’ system, and enforce a generic approach that overlooks the distinctive nuances of individual projects. Consequently, a sudden transition from ‘green’ to ‘amber’ might not truthfully represent a project’s actual condition. Moreover, ignoring key project-specific factors such as the project team’s experience and composition, and other complexities could thwart optimally project outcomes.

Envisioning a New Approach to KPIs

Considering these constraints, we advocate for a more adaptable approach to KPIs. KPIs should serve as flexible signposts, offering nuanced insights and evolving in response to dynamic project conditions. A ‘spectrum’ system could replace the binary ‘traffic light’ system to better encapsulate the subtle gradations between ‘good’ and ‘caution’, thereby enabling a more accurate snapshot of the project’s health and fostering tailored problem-solving and decision-making strategies.

Let’s illustrate this ‘spectrum’ grading: ‘Deep Green’ signifies a project operating ahead of schedule; ‘Light Green’ and ‘Yellow’ mark minor deviations that are manageable with slight adjustments; ‘Orange’ indicates a substantial deviation demanding dedicated intervention; ‘Red’ denotes a severe delay necessitating immediate action. This refined system facilitates proactive responses to project status changes and fosters a culture of continuous improvement.

KPI thresholds should be malleable, adapting to the unique context of each project and evolving in sync with the project’s progress to spur continuous learning and strategic adjustments. Influential variables, such as the project manager’s experience, sponsor involvement, project type, size, duration and team skillset, ought to be incorporated into the KPI thresholds to ensure a more precise and meaningful assessment of project performance.

Finally, KPIs should be viewed as living, evolving mechanisms, mirroring the project’s trajectory. This dynamic perspective fosters a culture of continuous learning, encourages periodic strategy adjustments, and aligns more effectively with the complex and fast-paced realities of modern project landscapes.

Advertisement
[widget id=”custom_html-68″]

 

Advantages and Challenges of an Adaptive Approach

Adopting an adaptive approach to KPIs unveils several compelling benefits. Primarily, this method fosters a responsive and agile project management environment, enabling teams to adeptly navigate changes and maintain momentum towards their objectives. By embracing flexibility, teams are encouraged to continually learn, refine their strategies, and progressively improve. This learning culture not only nurtures individual and collective growth but also enhances the potential for delivering value and achieving project goals.

However, implementing an adaptive approach is not without challenges. Critics may argue that tailoring KPIs for each project is a burdensome task, especially for organizations handling a vast number of projects. Indeed, creating individual KPIs for each project may seem daunting and resource intensive. However, this concern often underscores a deeper issue of mass governance in project management, where projects are overseen in a bulk, uniform manner, neglecting their unique characteristics.

Counterarguments and Solutions

To address these concerns, it’s important to emphasize that while individualizing KPIs requires upfront effort, the long-term benefits—enhanced accuracy, improved decision-making, and ultimately, successful projects—outweigh the initial investment. It’s about quality over quantity, shifting the focus from managing a large volume of projects to truly understanding and effectively managing each one.

Technology can also play a pivotal role in facilitating this adaptive approach. Advanced project management tools and software can automate the process of defining and adjusting KPIs, making it a less labour-intensive and more streamlined process. Organizations can gradually introduce adaptive KPIs. Starting with pilot projects could allow teams to gain confidence and experience with the approach and help refine the process before wider implementation. This gradual integration can help alleviate concerns and demonstrate the efficacy of adaptive KPIs.

Ultimately, transitioning to an adaptive KPI approach should be a thoughtful, well-planned process, considering the unique needs and capabilities of each organization. By doing so, we can address the legitimate challenges posed, while still harnessing the substantial benefits of this innovative approach.

Conclusion

In our rapidly changing project environment, the steadfast, conventional KPIs may no longer suffice. It is high time we welcome a shift towards an adaptive KPI approach, one that truly echoes the unique fabric of each project, appreciates the diverse shades of project progress, and continuously evolves in tandem with the project’s trajectory. This approach not only amplifies our project management effectiveness but also ensures that our success metrics are as diverse, resilient, and forward-thinking as the projects we orchestrate. By advocating this change, we lay the groundwork for a more realistic, precise, and insightful method of tracking project performance, fostering an environment that champions continuous learning, innovation, and strategic flexibility. With this, we can confidently navigate the complex waters of project management, steering our projects towards their destined success, one adaptive KPI at a time.

PMTimes_May17_2023

Best of PMTimes: The Why What and When of a Decision Log

Written by Brenda Hallman on . Posted in Articles.

Can you relate to that project that feels like it has been dragging on a little too long?

 

Moreover, your team is sitting in a conference room drowsy from preparing the final touches when one perky creative soul, who by the way missed the first four months of meetings (thus why they are perky), pops up with a question ‘Why are we doing it this way? We should look at a different option?’

Once the collective groans subside, everyone starts in on a chatter contemplating a different option. “Wait,” you think, “it has already been hashed out!” Quick, where are your notes? Where is that email talking about a different option? Was it in the meeting minutes somewhere? “When was that again? February?” This is all too familiar. You can’t quickly find the results, and you desperately want to stop all of the cross-conversation and new found excitement that has roused up the room. Then you sit back and remember, “Ah yes, I have a decision log!” You swiftly scan it, find the related item and pound your gavel on the table to gain everyone’s attention. It will all be fine, we are on the right track, and we don’t need to spend another moment of discussion because it was already agreed which would be the best action. Phew!

 

Utilizing a Decision Log, which is a list of critical decisions agreed upon throughout the project, has not yet leaped into mainstream project management practice, although it has started to gain traction being viewed as beneficial for recording impactful decisions and serving as a central repository for those decisions.

Why Do It?

The concept is a simple one. Once a discussion begins regarding a project, decisions are being made with some decisions essential for the direction of the project. Documenting those in a central location can be of value throughout the project as a quick reference and communication tool to assure everyone is aware of the direction.

Decisions may not always be agreed upon by the team members. Rather than opening a discussion for debate each time the topic arises, it is better to resort to the documented decision and move on from the topic.

 

Additionally, these decisions may be made in a forum that does not involve all team members, and they may be hidden in meeting minutes or informal email messages. Providing a standard method to document and communicate decisions can assure everyone is aware, avoid lack of clarification, and can be used as a method to focus team members when debate arises.

Decisions can be revisited when necessary, and may even be changed when new information presents to the project. Team members who raise valid points that counter a decision should be heard and their opinion valued as it may offer a better course of action.

 

Advertisement
[widget id=”custom_html-68″]

 

What Information to Include?

A decision log is a beneficial communication tool to assure all stakeholders are apprised of how a decision was reached, what other options were considered, and who is accountable for the decision. It provides guidance to the team members and can eliminate potential confusion. The format you use may be a spreadsheet, automated log, or another method that suits your environment.

The primary information to capture includes What is the decision, When was it made, Why it was made, and Who made it. Other information may be captured as well and may vary based on the project needs.

 

When to Include a Decision?

When to include an item in the log involves striking a balance between what is valuable to have recorded versus what is too detailed, and will take thought. As well as considering the overall audience, team members and project dynamics also consider these things:

  • Topics that are frequently debated or where there is often disagreement.
  • Decisions that may be confusing or not clear to all stakeholders.
  • Those made that impact the direction or future work of the project.
  • When alternatives exist, but only one must be selected.
  • Decisions made by leaders, or others outside of the project team, which will impact the work of those team members.
  • Those that impact what or how a deliverable will be achieved where it may be different than some stakeholders expect.
  • Items that may not seem significant but can cause issues if not understood.

As a project manager, you must judge what your stakeholders will view as too much detail. You also must consider not eliminating items that you think are valuable to minimize detail.

 

There you have it!

No one wants more documentation. That goes for the individual who must create and maintain it as well as the recipients who do not want yet another attachment to read. The value of the log is for the project manager to have a centralized location to capture items that may cause debate or slow progress or for those who are included to search for information on the project materials instead of hunting down the project manager. This can turn into a time-saver and worth a try it on your next endeavor!

 

Published on January 23, 2017.
PMTimes_May10_2023

Dealing with Failure and Setback as a Program Manager

Written by Vatsal Mehta on . Posted in Articles.

As a program manager, it is inevitable that you will face setbacks and failures along the way. While failure can be difficult to cope with, it is a natural part of the process of innovation and progress. By understanding how to handle failure effectively, you can turn setbacks into opportunities for learning and growth. Over the course of my career, I have had the opportunity to work on multiple programs of varying degree of scope, budget and schedule and have seen my fair share of setbacks, and I wanted to share some tips and tricks from my experience to help develop and hone your program management skills:

 

Understand how to handle failure: As a program manager, it is important to understand that failure is a natural part of the process of innovation and progress. When failure occurs, it is important to identify the root causes, learn from the experience, and take corrective action to prevent future failures. To handle failure effectively, it is important to have a proactive approach and be willing to take risks and try new things. It is also important to have a culture of continuous learning and improvement, and to encourage team members to embrace failure as an opportunity to learn and grow.

When I had suffered a failure on a project early in my career, I questioned if I was meant for this career. However, my mentor at the time encouraged me to reflect on the experience and consider how I could have approached things differently. They then had me apply this learning to my next project – which resulted in a much more successful outcome. Now, following each major milestone in a program, I conduct a postmortem to evaluate if I need to alter my execution method for continuous learning.

 

Report out openly and honestly: As a program manager, it is important to regularly report on the progress and status of your program to stakeholders, including team members, upper management, and clients. This helps to keep everyone informed and ensures that the program is on track to meet its goals and objectives. There are a variety of tools and techniques that can be used to report status, including project management software, status reports, and presentation software – the tool itself is not that important, what is important is that the stakeholders of your program are aware of progress. When failure occurs, it is important to communicate openly and honestly with team members about the challenges and setbacks that the team is facing. This can help to build trust and maintain team morale, even in the face of setbacks.

 

Advertisement
[widget id=”custom_html-68″]

 

Understand how to hold team members accountable: As a program manager, it is also important to hold team members accountable for their work and ensure that they are meeting their commitments and deadlines. This could involve setting clear expectations and goals, tracking progress and performance, and providing feedback and support as needed. There are a variety of tools and techniques that can be used to hold team members accountable, including performance management software, regular check-ins, and performance reviews. It is important to understand how to use these tools effectively to ensure that team members are meeting their commitments and contributing to the success of the program.

 

Take corrective action: Once you have identified the root causes of failure and learned from experience, it is important to take corrective action to prevent similar failures in the future. This may involve implementing new processes, procedures, or tools, or providing additional training or support to team members. By taking corrective action, you can help to reduce the risk of future failures and improve the chances of success for your program.

 

Communicate effectively with technical team members: As a program manager, you may often be working with technical team members who have specialized knowledge and expertise. To effectively communicate with these team members, you need to be able to understand and speak their language. This may involve learning technical jargon and concepts, or working with technical experts to translate technical information into terms that are easier for non-technical team members to understand. In the event of setback or failure this skill helps speed up the root cause process.

 

Understand how to maintain team morale: When setbacks and failures occur, it is important to maintain team morale and ensure that team members remain motivated and engaged. This can be challenging, but there are a variety of strategies that can help to maintain team morale, including:

  1. Communicating openly and honestly with team members about the challenges and setbacks that the team is facing
  2. Providing support and resources to help team members overcome these challenges
  3. Encouraging team members to take ownership of their work and to take risks and try new things
  4. Providing opportunities for team members to learn and grow
  5. Recognizing and celebrating successes and accomplishments, no matter how small

By following these tips and tricks and fostering a culture of continuous learning and improvement, you can effectively deal with failure as a program manager and turn setbacks into opportunities for growth and success.