Skip to main content

Tag: Planning

Walking The Reporting Tightrope in PMOs

Within project management, reporting stands out as one of the most critical services provided by Project Management Offices (PMOs). It serves as a crucial communication tool for fostering stakeholder engagement and is frequently highlighted as a major contributor to P3M (Portfolio, Programme, and Project Management) maturity. It’s also the area most stakeholders express a desire to enhance.

So, why must PMOs navigate a tightrope between reporting well but seemingly never well enough?

 

When executed effectively, reporting delivers timely insights, analysis, and information on key delivery matters. This empowers executives to make well-informed decisions that directly influence organisational success. However, when reporting falters, it not only raises the risk of poor decision-making but also jeopardises support for the PMO itself.

In achieving PMO reporting maturity, three factors are important: data, culture, and application. An organisation must gather ample data to conduct meaningful analysis. It must also have a culture that fosters and supports candid reporting of both favourable and unfavourable developments. Finally, it requires leaders to recognise the significance of applying and using collated information to inform their decisions and take appropriate action.

 

These factors however, interplay with each other considerably to affect reporting maturity within PMOs.

For example, data collection can vary across organisations. Some PMOs can collect data from all projects whilst others can only collect from a few.

Cultural differences also influence how PMOs handle reporting, with psychologically safe organisations able to conduct truthful reporting. In these organisations, red statuses are used to direct support into areas that are under stress. Less psychologically safe organisations lead PMOs and managers to avoid reporting altogether or to hide negative statuses. In these organisations red statuses are treated as pariahs and buried from view.

 

The application of reporting also differs amongst organisations, with effective boardrooms leveraging reports to inform their decisions. Others merely review data but don’t use it in their decision-making. From these observations, three key learnings emerge.

Data gathering remains challenging for organisations.

While visualisation software tools offer sleek dashboards, effective reporting hinges on robust PMO processes and stakeholder buy-in. The most effective PMOs treat stakeholders as customers, ensuring transparency and demonstrating the benefits of reporting.

Cultivate the right culture.

 

Advertisement
[widget id=”custom_html-68″]

 

Overcoming cultural barriers to reporting, such as a reluctance to report negative statuses, is essential. A shift towards collaborative working environments that welcome truthful reporting is necessary. PMOs play a pivotal role in facilitating this shift by nurturing collaboration and providing support for projects in need.

Reporting’s true value lies not in the data, but in its application.

 

Merely reporting data is insufficient. Having correct data reported is good, but without analysis, using it is hard. To derive optimal value from reporting, organisations must utilise it to drive informed decision-making. PMOs should therefore coach leaders to leverage reported data to help make impactful decisions that drive positive change.

Reporting is a tightrope walk for PMOs, it’s capable of either bolstering decision-making and organisational success or undermining it. By addressing challenges in data collection, fostering a supportive reporting culture, and applying it in decision-making, PMOs can elevate their reporting maturity and contribute significantly to organisational success.

Adapting Agile Principles for Successful Maintenance Hand-Overs

Over the 20+ years since the Agile Manifesto was created, more and more organizations see agility as key to success, especially for software development. Agile methodologies have revolutionized the way teams approach software development, emphasizing flexibility, collaboration, and continuous improvement. Ideally, there are Product Teams that handle development and maintenance throughout the product’s lifecycle. But what happens if development and maintenance are handled by separate teams?

This scenario can be problematic, especially if the teams are using are using different methodologies, or belong to different organizations (e.g. in-house and contractor teams). What happens when it’s time to transition control of a software project from the development team to the maintenance team? Can Agile principles be applied to facilitate successful hand-overs? In this article, we’ll explore how Agile principles can be adapted and applied to ensure smooth and successful software transitions.

 

Understanding Agile Principles

Before we delve into how Agile principles can be adapted for software transitions, let’s briefly review some the core principles of Agile methodology. Agile is built on four foundational values and twelve principles, as outlined in the Agile Manifesto. These values and principles emphasize:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan (flexibility)

 

Adapting Agile Principles for Transitions

Now, let’s examine how these Agile principles can be adapted and applied to facilitate successful software transitions:

  1. Flexibility: Agile methodologies prioritize flexibility and adaptability, allowing teams to respond to changing requirements and priorities. Similarly, in software transitions, flexibility is one key to navigating unforeseen challenges and adjusting plans as needed. By adopting a mindset embracing change, teams can proactively address issues and adapt their approach to ensure a smooth transition.
  2. Collaboration: Collaboration is a cornerstone of Agile methodologies, with teams working closely together to deliver value to customers. In the context of software transitions, collaboration between the development and maintenance teams is essential for success. By fostering open communication, sharing knowledge, and working collaboratively to address challenges, teams can ensure a seamless hand-over process.
  3. Continuous Improvement: Agile methodologies also emphasize continuous improvement, with teams regularly reflecting on their processes and seeking ways to enhance efficiency and effectiveness. Similarly, in software transitions, teams should evaluate their transition processes, identify areas for improvement, and implement iterative changes to optimize the hand-over process over time.

 

Advertisement
[widget id=”custom_html-68″]

 

Applying Agile Practices to Transitions

In addition to adapting Agile principles, teams can also apply specific Agile practices to facilitate successful software transitions. Some key Agile practices that can be applied include:

  1. Iterative Planning: Adopting an iterative planning approach to break down the transition process into manageable iterations, with regular checkpoints to assess progress and adjust plans as needed.
  2. Daily Stand-Ups: During the transition period consider holding daily stand-up meetings, where team members share updates, discuss progress, and identify any impediments. The goals is to facilitate communication and alignment between the development and maintenance teams.
  3. User Stories: Creating user stories to capture requirements and priorities from the perspective of the maintenance team can help ensure that the transition process is aligned with the needs of the end-users. Even more importantly, user stories that include updating and maintaining the software and likely rule or data updates will improve the maintainability of the software itself.
  4. Retrospectives: Conducting retrospectives at key milestones during the transition process allows teams to reflect on their experiences, identify successes and challenges, and brainstorm improvements for future transitions. These should also be communicated across teams and product groups.

 

Applying Agile Principles in a Software Transition

To illustrate the application of Agile principles in software transitions, let’s consider a hypothetical case study of a software development company transitioning control of a web application from the development team to the maintenance team:

  1. Flexibility: When unforeseen technical challenges arose during the transition process, the development and maintenance teams collaborated to adjust their plans and implement creative solutions, ensuring a successful hand-over despite the challenges. This included adjusting target dates and budgets for both teams to provide the time and resources needed.
  2. Collaboration: Through regular stand-up meetings and collaborative planning sessions, the development and maintenance teams worked closely together to share knowledge, address issues, and ensure alignment throughout the transition process.
  3. Continuous Improvement: Following each milestone in the transition process, the teams conducted retrospectives to reflect on their experiences and identify opportunities for improvement. By implementing iterative changes based on these retrospectives, the teams continuously optimized their transition processes over time. These were shared with other teams, along with tools, templates, and tips that had proven useful during the transition.

 

Conclusion

In conclusion, Agile principles can be effectively adapted and applied to facilitate successful software transitions from development to maintenance. By embracing flexibility, collaboration, and continuous improvement, teams can navigate the complexities of transition processes with confidence and ensure a seamless hand-over that meets the needs of end-users. Through the application of specific Agile practices and a commitment to Agile values and principles, organizations can optimize their transition processes and set the stage for long-term success in software maintenance.

If your organization uses Agile methodologies with development and maintenance handled by different teams, how are transitions handled?

Brewing Success: Managing Your eLearning Project One Cup at a Time

Coffee is a staple of my morning routine.  With little deviation, I make my coffee as soon as I sleepily saunter into the kitchen.  I don’t think much about it, the process is nearly hard-coded at this point: choice of favorite mug, mug placed, coffee prepped, brew cycle on- then I await the pop-pop-popping of hot water as the sweet aroma fills my kitchen. My brain is hyper focussed on both the sounds and smells like a Pavolivan trained dog awaiting the liquid award.  Then finally, I add cream and a touch of honey (yes honey, it’s delicious!) and after my first sip, my morning is ready to begin.

 

I get it. I’m in a rare class of those who need this cup of coffee to go beyond the simple, great, I have coffee.  I admittedly spend a lot of money on this caffeinated nectar.  It’s my one true pleasure each morning. I have a deep appreciation for connoisseurs who hone their skills and master the art of selecting beans, grinding them to perfection, and brewing a rich, flavorful caffeinated beverage. I read about coffee entrepreneurs and love to smell fresh beans when I’m in a coffee shop.  I even enjoy reading the descriptions of flavors: medium body with tasting notes of nutty, sweet chocolate, mild citrus and a bright finish….yes please, I’ll have a cup of that!

 

I realize that for the vast majority of the population, the process behind an excellent cup of coffee doesn’t really matter, it’s about the end result done right.   Yet one morning, I started thinking about both my morning routine and the overall coffee process, going from a bean in a field to a liquid in someone’s cup. And that’s when it hit me that the process of making coffee bears a striking resemblance to eLearning project management.   As it happened that morning, I had a busy day of deliverables and thought to myself, “huh, as clients receive their final deliverables, they’re likely unaware of all the careful planning, execution, and evaluation that goes on behind the scenes. They want their deliverable, done correctly and as expected”.   So I set out to write about the two processes and their similarities.

 

Selecting the Right Beans (Project Initiation/Needs Assessment)

A high-quality, aromatic coffee bean sets the foundation for a rich, silky cup of Java and a well- organized pre-project launch process is paramount to the success of an eLearning project.

For example, a coffee’s success includes bean variety, the growing region, climate (including altitude) and how the beans are harvested and processed.  Typically, there’s no need to think about anything else in the process. Sound familiar?

 

As PMs, the project initiation phase is arguably the most critical stage of the entire project.  Above all other tasks, a PM’s job is to review and/or confirm the target audience, determine what, if any constraints or risks are present, understand scope, draft a schedule, confirm resources and ensure that all source materials were shared. In other words, conduct a thorough needs assessment.   An air-tight project initiation sets the stage for a balanced and mellow project experience. Again, if done right, there’s no need for your learners to think about anything else in the process.

 

Measuring and Grinding (Project Planning)

Precision is key in both coffee and project planning. How one grinds coffee beans will play a significant role in the flavor, aroma, and strength of your final drink.  If your beans aren’t measured correctly before grinding, or if the grind size doesn’t match the intended strength, that cup of coffee will taste acidic, weak, or sour, all things I cannot tolerate.

 

In eLearning, the best way to avoid a weak project finish is early preparation to ensure that all team resources are informed of the project objectives, deliverables, schedule and risks. An eLearning project is only as successful as the individual parts.  The more project information a PM shares with the project team members, the higher the probability of success.  Kickoffs are the best way to communicate with your project teams.

 

Kickoffs ensure that your team understands the schedule, the deliverables and that everyone knows the part they’ll play in the project.  It’s a time for the team to ask questions, get to know each other if they don’t already, and to understand accountability for the project success.  Projects started without kickoffs often go sideways because they’re missing precision from the start.   Take the time to measure the project needs beforehand, so that your project begins from a position of strength.

 

Advertisement
[widget id=”custom_html-68″]

 

Power on- Whirring, Sizzle, Gurgle, Drip! (Official Project Kick-off)

Few things are better to coffee lovers than hearing the sound of the coffee machine preparing for your morning brew. It’s surely my favorite part, as I detailed at the start of this story.

 

The official kick-off with your learning team is akin to powering on your coffee machine.  Kick-off meetings are the time to confirm project scope, timing of milestones, agreements around project responsibilities, establishing meeting cadence, verifying source material status, and highlighting risks.  Kick-off meetings set the foundation for a strong project start.

 

The best way that PMs can level-set expectations is via note-taking.  Holding everyone on a client call responsible for their individual or collective parts is key, and live scribing is highly suggested so that the collective team agrees to action items and deadlines.  With the advent of AI-based tools that are creating quite the sizzle in our industry, note taking is easier than ever before so there’s no need to skip this important step!

 

Brewing (Project In-Flight, Monitoring & Control)

Obviously, the best part of the brewing process is your satisfying cup of coffee.  The preparation of your coffee beans invites the flavors from coffee grounds, and at that point, your coffee should brew as expected.  Still, like any process, problems might arise.  For example, the water temperature (targeted between 195°F to 205°F) could be off, or the wrong type of brewing method is used for the ground type which would heavily influence the role in flavor, or worse yet, user error- inserting the wrong sized filter or not measuring the water correctly.  Keeping a close eye on the brewing process throughout and adjusting parameters as needed is the best way to achieve and brew the perfect cup.

 

Similarly, an eLearning project that is meticulously and methodically organized (during initiation and planning), should percolate to an ideal state, assuming the PM’s involvement includes excellent communication, detailed awareness, shared notes and prompt resolutions.   Regularly assessing project progress is critical so that you can identify and rectify any issues quickly.  Incorporating feedback from stakeholders is an ideal way to glean that your near final product is meeting/has met expectations.

 

Ask open, thoughtful questions during status meetings that begin with “How”, “What”, or “Tell me” as examples.  Sending short (3 question max) surveys mid-project works too.  Dropping a quick email that simply reads, “I am interested in hearing your feedback around how the project is progressing to date” could glean rich insight of an issue that may have not been covered during a standing meeting.

Enjoying the Final Cup (Project Closure)

Finally, it’s time to serve your eLearning project like a perfectly brewed cup of coffee. Present the finished product to stakeholders and ensure they have the tools and knowledge to make the most of it. After successfully conducting LMS testing and launching, your project is complete.  Celebrate your team’s hard work and savor the sense of accomplishment.

 

And so, much like brewing a good cup of coffee, managing an eLearning project involves distinct phases, each crucial for a satisfying end result. Skipping or rushing through any phase can lead to a less-than-desirable outcome. By carefully tending to each step, eLearning project managers can ensure a successful and effective learning experience for their audience.  If you brew your eLearning projects with the same care and precision as you would your favorite cup of coffee, you’ll serve up excellence every time.

The Rhinoceros In The Room (Risk Analysis and How to Tame Your “Unicorn”)

Imagine going to the pet rescue organization in your town to get a new pet, and you look at several adorable dogs and cats, and then the staff person says, “Well, there’s one that we’re not sure we’re going to be able to find a home for. Would you like to see him?”

You’re there to help make a rescue and get a new furry friend, so you say, “Of course!”

The staff member takes you to the end of the row, where there’s an enormous pen with a rhino inside.

You say, “That’s a rhinoceros!” as though the staff person didn’t know that already.

They say, “Yeah! He has a horn. They make great pets because they always go to the bathroom in the same place.” (This is true, by the way.)

You say, “Yeeaaaah…but he weighs 6,500 lbs., has a horn, and can run 30mph.” (This is also true.)

They say, “But they go to the bathroom in the same place every time. Think of how much easier that is than cleaning up after a dog!”

 

It’s a comical episode, but we often do the same thing in risk analysis. The temptation is to come into risk analysis with pre-conceived notions, or even just so intent on committing to the project as is we’re unaware that’s not a unicorn staring us down. Consequently, we discuss how an Australian Shepherd can get bad hips late in life but forget that a rhino can destroy your house by turning around when you call his name.

So, let’s talk about how to recognize the rhinoceros in the room.

 

Overview

Risk analysis is the process of identifying, assessing, and prioritizing potential obstacles or stoppers before they derail your project. It involves a meticulous examination of what could possibly go wrong, the likelihood of such events, the potential impact of those worst-case scenarios, and the strategies for mitigation. We must foresee the unforeseen, prepare for the unpredictable, and make sure that a project is not merely feasible, but in the worst case will not harm business continuity or exceed allowable energy or resource expenditures.

Without a comprehensive risk analysis, projects can easily miss deadlines, overshoot the budget, suffer severe scope creep, or otherwise hinder not just the project in question but the business as a whole. The consequences can range from mild setbacks to catastrophic failures, affecting not just the project but also team morale and organizational reputation.

 

Advertisement
[widget id=”custom_html-68″]

 

Methodology

Identification:

The first step is recognizing that a rhino, for all its intriguing attributes, poses certain…ahem, “challenges” as a pet. Brainstorm and list all risks, as absurd or unlikely as they may seem.

 

Assessment:

Next, evaluate each risk based on its likelihood and potential impact. It is truly critical that you measure both sides of the equation; A potential problem that has little impact, like a few users needing help installing new software, probably doesn’t warrant a four-hour meeting and approval from the board of directors before proceeding. Conversely, an unlikely problem with severe consequences, like the credit card system going down on Black Friday, absolutely needs mitigation before proceeding. This is where quantitative and qualitative analysis techniques come into play, understanding the nuance of each risk.

 

Mitigation Strategies:

Finally, develop strategies to manage the risks that warrant attention before proceeding. This could involve anything from contingency planning to risk transfer mechanisms, all aimed at reducing the likelihood of risks or minimizing their impact should they materialize. In the worst case, at least assign a risk owner to keep an eye on a potential risk so nothing sneaks by you.

 

Conclusion:

The discipline of risk analysis in project management is about foresight and preparation. Balance your desire for a pet against the wreckage that overgrown unicorn can bring to your life. Equal parts caution and courage, pragmatism and progress, and dreams and dependability. By thoroughly analyzing risks, your projects are more likely to succeed, and you might even be able to sleep better.

Risk analysis is not just a task; it’s a mindset, a culture, and a practice that distinguishes successful projects from pet rhinos.

Cumulative Cost and Budget Spreadsheet Tool

As both a Project Management practitioner and a College Professor and University Instructor, I have found that there are very few simple-to-use templates for creating a time-based project schedule and budget. This package has a series of 4 Excel spreadsheets (but any standard spreadsheet program should also work) that allow a student or practitioner to build a time-based budget that shows unit activity (scope) planned period (time), and cumulative cost all on one page. It has been created to demonstrate a fictitious but realistic budget for the purchase, installation, and testing of a mid-size local area network of about 200 desktop and laptop computers and  5 servers. The project is expected to take 15 weeks from start to finish with a total budget of $402,200.

4 spreadsheets in total allow readers to copy and build their budget.

Sheet 1,2,3 shows the building blocks of creating a time phase schedule for buying and installing laptops, desktops, and servers. Unit activity and planned unit prices drive the planned equipment budget. Similarly, there are a few human resources planned with daily labour rates driving the total labour cost plan. The summary cost lines from the equipment and labour detail sections are then summed to yield the total planned cost for each week and cumulatively.

Sheet 1 shows the numeric data entry only. It was started at row 30 to leave space for a data-driven graphic table to be added later.

Download Sheet 1

 

Sheet 1 15-week budget before a graphic table with input cells yellow. This is the same as sheet one except for the user input cells for unit installations, unit prices, labour days, and labour rates have been shown on a yellow background to ease of use. The other cells are formula-driven.

Download Sheet 1 with Yellow Input Cells

Sheet 2 shows the addition of a data-driven graphic table inserted above the numeric spreadsheet. The instructions for creating the table are:

  1. Select (curser click on) rows 35 and 36 to include all cells from C35 to Q36
  2. Click on the Insert tab from the top of the spreadsheet
  3. Click on the Column Icon
  4. Select (Click on) the top left 2-D column icon

Download Sheet 2

 

Advertisement
[widget id=”custom_html-68″]

 

A two-column graphic showing the weekly planned cost and total cumulative will be superimposed on your spreadsheet. It will not likely be properly positioned or sized to line up with your numeric entries and weekly columns. You will need to use your cursor to grab the corners of the graphic table to stretch and position the table to line up with your numeric entries.

Sheet 3 is the same as spreadsheet 2 after the graphic column table has been stretched and positioned to fit above the numerical data it represents.

Download Sheet 3

 

Sheet 4 adds a Gantt chart showing key milestones and dates.

Download Sheet 4