Previous month:
January 2019

Agile 2019 Presentations

DC ConferenceI learned this week that two of my presentation submissions for the Agile 2019 conference in Washington D.C. August 6-10 have been accepted. I was very lucky to get two accepted as they received nearly 2,000 submissions for around 250 slots. It should be fun and I am really looking forward to it.

My talks will be on moving beyond agile approaches and case studies in transitioning from projects to products.  Here are the outlines:

 

The Future Looks Awesome, and Moving Beyond Agile - The Future of Agile Software Development (IEEE Software) track. The Future is Awesome

“Agile approaches succeeded and changed the way we work. They brought the philosophy and tools previously used by only the high performing teams to the majority of organizations. Now it is time to move beyond them and embrace a new wave of emerging ideas and approaches.

It is short-sighted and self-absorbed to imagine agile approaches represent the best way to execute all work types. As new technology, products, and services emerge, we need new ways to deliver them. Likewise, as organizational structures evolve to use this technology and integrate the aspirations of next-generation workers - who grew up in a digital world, our approaches much evolve again.

Fortunately, patterns are emerging from new organizational structures and the lessons from failed agile transformations. Agile’s “Family” mindset of empowerment and values-driven culture is being overtaken by “Organism” and “Community” mindset organizations embracing Holacracy and Teal Organization ideas. People are also realizing not everyone wants to adopt an agile mindset and we need better ways of integrating with more traditional models that remain that way for their own advantages. The future involves further expansion and integration, not more fervent conceptual conversion.

Come and examine the future beyond agile and hybrid agile. Explore the trends in corporate structures, career aspirations, engagement models, and the technology that is making it all possible. The future is exciting, dynamic, and decidedly less agile – but in a good way.”

It will be a fast-moving presentation recapping the rise, role, and results of agile approaches before moving onto emerging trends. Through case studies of successful organizations, we will explore new patterns in work, the worker, and the workplace.

Agile approaches play an integral role and will continue to in the future. However, they are already being augmented and extended by additional models and techniques. Using a “Yes, and…” mindset of combining approaches we examine emerging trends and what they may mean for the future of collaborative work.

 

PotholeSpeed-bumps and Potholes on the Road from Projects to Products - Experience Reports track.

“Transitioning from projects to products made perfect sense for my client. Much of the business was digital and their websites / online-services would not be “completing” or going away soon. Development was deliberately continuous, and executives embraced this as both inevitable and desirable. However, just because it was the logical thing to do, it did not mean it was easy.

Maybe if we did not have over 100 inflight projects executing simultaneously, we could have picked an easier starting time? Maybe if there were not so many dependencies between teams, work would have been easier to untangle? Maybe if they were not in the midst of transitioning to microservices and new hosting technology, the technology challenges would have been easier to resolve?

Most organizations considering the transition from projects to products have similar challenges. By definition, “transitioning” means doing things mid-process; otherwise, it would be “starting fresh with product development” – and where’s the fun in that?

This experience report recounts the story and transformation from slick PowerPoint slides to people problems and development difficulties. We did survive the journey and arrived in the land of continuous digital delivery, but we took some detours and lost some paint along the way. If you are considering the switch from projects to product development, maybe we can help you avoid some potholes and speedbumps along the road. Being forewarned is to be forearmed, but each journey is different, and as they say, your mileage will vary.”

It recounts my experience as a consultant working with the leadership team and development teams. There was general agreement that a shift to organizing around products made sense, but disagreement on the best way to get there. Rather than a big-bang changeover, we adopted a ripple-out, incremental approach. This allowed us to review and monitor for issues before spreading approaches to more teams. Naturally, the executives wanted everything done at once and the teams wanted to be left alone until after the next release.

Not being able to please everyone, we developed a workable plan and rolled out the changes to teams, technology, and supporting groups. We experienced many obstacles such as having to rewrite vendor contracts, get exceptions from accounting for budget processes and from HR for reporting changes.

More details about the Agile 2019 conference in Washington D.C. can be found on the official website.


New PM - The What?, Why?, and How? of Project Charters

Project CharterCreating a great project charter is an art and a science. Anyone new to the profession of project management needs to learn how to create a project charter. It is not only an important early project deliverable, but it also sets the tone and lays out the foundation for the rest of the project.

While we can spend our careers improving our ability to craft effective project charters, we can get to a 70% good-enough state by addressing some basic topics. This article explains those basics.

Context is Crucial
First, it is critical to understand that context matters. The definition of what makes an acceptable—or great—project charter will vary from organization to organization. It will also be driven by factors such as project size, criticality, type, approach, etc.

The project charter for kicking off a safety-critical public works project will be very different than a charter for a small internal project to, say, build a tool to recover disk space used by duplicate files.

Large, critical projects will require large comprehensive charters. These can take teams of experts weeks or months to create. Small projects will likely have their three- to eight-page charter written in a day or two by the project manager. When creating (or reviewing) project charters, we need to understand this context. Ask, what is appropriate? What level of rigor and detail does this effort require and deserve?

To start the chartering process, we first need to understand a few things about the project goals and our internal processes.

  • For the project, we need to understand the business case and an outline of the desired scope.
  • For our organization, we must understand any strategic plans we need to align with, our standards and processes, contracts to use, and any relevant external factors like market conditions and industry standards.

Once we know these things, we can start writing our charter.

Make it Clear
I am a simple person and like simple ideas and definitions. I probably miss subtle nuances but have learned that most people appreciate simple, clear documents. The style points we lose for a lack of sophistication are made up for by improved comprehension and clarity. So, my definition of a project charter is a document that authorizes the project and explains the what, why, where, when, who and how aspects of the project.

We can call the whatwhywherewhenwho questions W5 and add a “+” for the final how question. Provided the project charter answers the W5+ questions and provides approval to start the project—all at the appropriate level of rigor—it’s a winner. So, let’s get started by reviewing each question…

What?
In your project charter, you will not call the section “What?” It will likely be called “Scope” or something similar. The “W5+” idea is just a tool to make sure we address the important sections. So, in the scope section, we would describe or list the major deliverables or high-level functionality the project should deliver. People need to understand what we are talking about before they can appreciate further details such as schedule and approach.

When defining what the project will deliver, it is also useful to state what it will not deliver. So, a list of “out of scope” items is also valuable. It is better to have sponsors or user representatives complain now rather than halfway through the project (or worse, at completion when there is nothing we can do about it) that their anticipated element will not be delivered.

Why?
The why of a project is described in a “Problem Statement” or “Business Need” section. Some people put this section before the what. That is fine; follow your organization’s standard, or the preferred sequence of who approves project charters (or failing those, your own preference). Just make sure the what and the why are addressed early on.

People need to understand why this project is important. What new revenue will it bring? What problem or legal requirement does it serve? What new opportunities, new products or new customers do we hope it will attract? Projects are expensive and risky endeavors, so we better have a good reason to undertake one. The business case or problem statement is where we describe it.

It needs to be clear and compelling. It may reference a separate business case or return on investment analysis. If these components are necessary and not in separate documents, include a summary in the charter body and put the details in an appendix. We don’t want people to stop reading our project charter because they came across pages of calculations.

Where?
“Where?” can seem a strange question, maybe inserted just to get the “W” count up to five. However, think broader. Which markets, products, and departments are we impacting? Where is the project going to touch our organization, customer base, and market segment?

Remember: The project charter normally provides approval for a project to start. We need to provide the relevant context so people are thinking appropriately before they approve, reject or request changes be made.

This information may be contained in a section called “Organizational Impact” or form a sub-section of the scope section. It also explains how the project is aligned with the organization’s strategic plan.

When?
This is where we describe the “Project schedule”—not only when we plan to start and (hopefully) complete the project, but also major steps along the way.

Being a project manager writing a charter, it’s easy to get caught up in the apparent importance of your project. You might assume that once approved, the organization will rush full-steam ahead into kickoff and execution. We need to inject some caution and realism. What seems important and obvious to us is often low priority for the sponsors or those already over capacity in executing existing projects and operations. Things might take a while to get going.

So, do not build a schedule based on starting work immediately after approval. That just sets everyone up for failure. The most common source of late project completions is not poor estimating or a lack of risk management, it is late starts. Every late project I have reviewed had a late start. They may also have been terrible at estimating and blind to common threats, but late starts are very common. We need to explain that real end dates are driven by real start dates.

Projects get delayed for a host of common reasons. We were delayed in getting our team, we were delayed in finding a space, we were delayed in accessing funds. So, do yourself (and everybody else) a favor and explain that the project will likely take three weeks, months or years from having the requisite start conditions.

We also need to be realistic about uncertainty. The uncertainty associated with our estimates needs to be reflected (to some degree) in our schedule. It is probably not acceptable to say, “We have no clue when we will be done.” But do not commit to completing within a certain timeframe unless you have a realistic and robust plan for achieving that.

Robust means including contingency to address uncertainty. Be open about it, such as, “We included a 15% buffer for unanticipated work.” You might get asked to remove it and “work smarter” or “find a way, damn it!” and that is fine. You reflected the uncertainty inherent with the work. Depending how supportive the sponsors are, we could consider explaining that removing contingency is accepting the risk of an overrun due to learning in the future things that we do not know today.

Plans and estimates created at the beginning of the project are, by definition, the least reliable because that is when we know the least about the project. It is only when we begin to execute that we learn about its true complexity and the actual abilities of the team, vendors and supporting groups. Sponsors usually don’t want to hear this kind of smartass insolence from the project managers. PMs are hired to deliver projects, not tell them how to set stretch goals or run a business.

There are other ways to shorten a schedule. We can cut the scope of what is delivered. This could allow us to hit a deadline and maybe have a follow-on release for lower-priority work. It is not ideal and is really wriggling out of the defined scope. However, for software products, where must-have and nice-to-have features are more fluid, it could be a viable option.

We can also add more people to the project. This works great if you are undertaking simple work like digging ditches or building pyramids. For anything more complex that involves problem-solving, idea sharing and collaboration, books like The Mythical Man-Month explain that adding people to a project that is late will make it later (while spending more, too).

For these reasons (and others learned the hard way), make sure schedules clearly contain contingency to reflect uncertainties. Also, ensure that schedules work from a project start date that is contingent upon having prerequisite project conditions in place. Yes, they might both get ignored, but it is the responsible thing to do—and you can bring them up at steering committee meetings when asked why the project is behind.

Who?
The who question represents the “Team” and “Stakeholder” sections of a project charter. It is normal to show org charts of core project roles and list known team members and open positions. RACI charts can be used to list who is responsible, accountable, consulted and informed (RACI) for work and deliverables.

We should understand that the term stakeholder encompasses not only the people working on the project and sponsoring it, but also everyone it will impact. This extended family of project influencers include suppliers, customers, and even the general public if the project is likely to draw public opinion. Obviously, we do not list these broader communities by name, but we should identify them and assign a contact within the project for managing that group.

The PMI definition of a stakeholder includes not only those impacted by the project, but even those who perceive they may be impacted by the project. This is important—the scope of people who may influence development is wide. It is better to have a plan for engaging or at least monitoring these groups (be them environmental, minority or special interest) before they can blindside the project. Inventing a fire-response plan is always easier to do before you also have a fire on your hands.

How?
The how question reminds us to explain the “Project Approach.” We should describe how the project will be executed. Will we be following the standard corporate project lifecycle? Are we trying a new approach? Are we outsourcing portions?

People need to understand how the project will be executed before agreeing to fund it or participate in it. If they think the project has merit but we are suggesting to go about it all wrong, they will want the ability to influence the approach used.

When we are following a standard approach, it is sufficient to just name it. When we are proposing something different, we need to describe it in more detail. This could be a reference to another document or pointer to an appendix in our project charter.

Approval
The charter describes the project from a holistic perspective by addressing the W5+ questions; it also provides the approval/authorization to start work. In most organizations, approval of the charter triggers a request for funds or authorization for expenditure (AFE). For this reason, we need some formality around the approval and sign-off of the charter. It is normal to have a signature section for sponsor, division leads and other steering committee members.

The approval circumstances are rarely as simple as either approved or not approved. It is usual to have definitions of the various options that the steering committee may use. Common status options include:

Approve – Looks good, let’s get started
Approve with modifications – Will be okay if you make these changes (provide some space in the signature area to hand-write requested changes and then get signatures)
Request changes – Major changes are required and a new charter will need to be submitted
Defer – Not at this time, keep on hold
Reject – No, do not proceed

What about agile projects that do not have charters?
Today’s agile projects produce fewer documents. However, since charters often authorize work to start and trigger the release of funds, we still sometimes see them used in hybrid traditional/agile environments. If project charters are not used in name, typically a lighter-weight deliverable with a different name is used.

We might see an Agile CharterProject Skinny or Product Canvas. The purpose is similar—describe the endeavor and get agreement to start. When working with agile approaches, we can still use the W5+ idea to make sure we address the common viewpoints. The coverage in each section will likely be brief, but is still helpful.

Summary
Consider the context you are working in. Organizational standards and project characteristics such as size, cost, and impact of failure will dictate the level of detail and rigor that will be necessary. Then keep the sections simple and clear. Use appendices or references to external documents if sections become too long. We want people to be able to read the core body of our charter through in one sitting and then make a decision to approve it.

Make sure the sections address the W5+ views of the project one topic at a time. For instance, do not mix schedule with business justification; keep them separate. Do not paint yourself into a corner by committing to unrealistic delivery dates or optimistic costs. Present what you believe is realistic and let the steering committee assume the risks of reduction (if possible).

Recommending a template is problematic since organizational needs vary, but common sections for a small- to medium-sized project might contain:

  • Introduction – Explain the purpose of the charter
  • Problem Statement – Outline the what
  • Scope Outline – More detail on what would be delivered
  • Definition of Success – Define what “done” would look like
  • Risk Summary – Review the high-level threats and opportunities identified
  • Constraints and Assumptions – Outline the accepted operating parameters used
  • Business Case – Explain why the organization should do this
  • Schedule – Explain when the project will be completed
  • Deliverables Schedule – Outline when the key deliverables will be completed
  • Budget – Explain how much this is likely to cost
  • Team Structure – Outline who will be working on the project     
  • Organizational Structure – Explain who will be responsible for oversight and direction
  • Project Approach – Explain how the project will be run
  • Steering Committee Decision – Record the approval (or otherwise) of the charter
  • Appendices
    1. Project Background – Supporting material about why this is a good thing to do
    2. Deliverables List – A list of what should be delivered and what Done looks like for each
    3. Deliverables Schedule – A schedule for the deliverables’ leave some wiggle room
    4. Risk Assessment Detail – Details of the threats and opportunities analyzed to date
    5. Communication Plan – Details of how people will be kept informed about progress and issues

[Note: I first wrote this article for ProjectManagement.com here ]


New PM, New Choices

Choices(Over at ProjectManagement.com January’s theme was “New PMs”. I wrote this article about the choices of approach we have and ways for new PMs to navigate them.)

These days, new project managers are exposed to conflicting guidance. On the one hand, there is a plethora of traditional “Plan the work, work the plan” literature. On the other, media is full of light-touch, self-organizing team advice. These sets of recommendations often appear to be at odds, so what is the new PM to do? Consultants will say, “Oh, it depends…” and start a lengthy (aka expensive) conversation. I say let’s examine the basics so we can make an informed decision ourselves.

The goals of planning, scheduling, and tracking are universal. We need to understand what work needs to be completed, determine a good way to do it, then make sure it happens while making adjustments as new information emerges. However, in the last 30 years, we have started tackling more projects with higher degrees of uncertainty and change. These characteristics help us determine if we should use traditional, predictive approaches or rely more on newer, adaptive techniques.

When our projects undertake defined, repeatable work using technologies and approaches our organizations have experience in, then uncertainty and change rates are typically low and manageable. Here, traditional project management approaches work great. It is safe and effective to use Gantt charts, detailed work breakdown structures (WBS), network diagrams and earned value analysis.

Yet when projects use new (to us) technology and tackle problems our organizations have not solved before, then risk, uncertainty, and rates of change will be high. Traditional approaches have plenty of tools for handling risks, uncertainty, and change; but modern, adaptive approaches were purpose-built for these types of projects and have proven to be effective in these circumstances.

Work Characteristics, Not Industries
It is important that we examine work characteristics, not just the industry domain we are operating in. It would be easy (and wrong) to classify all construction projects as candidates for traditional approaches, and all IT projects as needing an agile approach. Instead, there are plenty of experimental construction projects using new designs, materials and assembly approaches. Likewise, there are defined, repeatable IT projects that can (and have been) successfully managed using meticulous planning, detailed estimation, and formal change control procedures.

So we need to dig deeper and see if we are dealing with low-variability tasks or more consensus gathering and problem-solving. These work types often change depending on which phase of a project we are working on. Designing something is typically a consensus-gathering and problem-solving exercise. Here, formal planning and estimation are difficult because we don’t know what we will encounter.

Consider the process of designing a new car or home. We have a combination of creative goals (produce something new and appealing) and engineering goals (meet specifications, constraints). The process is likely to be iterative and adaptive. We are looking to build consensus between stakeholders, who include sponsors (concerned with value, schedule, quality), designers (aesthetics, features) and engineers (performance, practicality).

This design phase requires collaboration between subject matter experts and probably iteration on prototypes to confirm understanding and validate ideas. Approaches like lean, kanban and agile work well in these uncertain, high-change environments. Their tools for experimentation, rapid feedback, reprioritization, and improvement help generate consensus on designs and drive uncertainty out of models.

Then, once the design is agreed upon, the process of production is typically more defined and repeatable. Unless our car or home is using new technology, materials or assembly techniques, the process of actually turning designs into completed examples should be less uncertain and iterative so more predictive approaches to work management can be used.

Physical projects—which manipulate tangible materials like concrete, steel, and plastic—have significant production phases where predictive approaches can be employed effectively. Digital projects—which manipulate intangible data and algorithms—have no production phase since the process of turning code into executable software (the process of compiling code) is automated.

Physical Project Characteristics

So, software projects remain in the design phase—that early, upfront, uncertain period where subject matter experts are collaborating to create something that has likely not been done before.

Digital Project Characteristics
There will be many trade-offs between design goals and implementation practicality to be made. All the divergent stakeholders will have divergent goals. The sponsors want fast, cheap and high quality; the users want their work simplified and streamlined so they can focus on their goal. The development team wants interesting work using new technology and skills to further their craft.

Once we understand what work types suit predictive and adaptive approaches, we can make better sense of our projects. Having said software development is design phase focused, it’s important to understand most IT projects do more than just software development. Tasks like ordering equipment, installing hardware and training users can all benefit from predictive planning and management techniques.

A Case Study
A couple of years ago, I worked on a project to develop and install routing software for truck drivers. This combined custom software development, integration with commercial off-the-shelf (COTS) software, and hardware installation that required wiring into the truck’s engine management system and installing GPS transmitters, tablets, etc.

The custom software development was easy to plan (but not easy to do). It was new, uncertain and benefitted from an agile approach. Integrating with the COTS software was a hybrid process. We worked with the vendor to iteratively tackle the highest risk and highest business value portions first. However, being just one customer of many, the vendor did not have the availability to serve our needs as quickly as we would have liked.

We worked on a monthly delivery cadence maintaining a backlog of issues and features to tackle next. Due to previous disputes about charges, the working relationship with the vendor was quite adversarial—so detailed statements of work and a formal change control process was followed. This consumed quite a bit of time for both parties, time that could have been focussed on feature development—but that reflects the reality of many commercial projects. We have to make the best use of what we have, given the current circumstances.

Installing the equipment in the trucks demanded precision timing, OCD levels of planning and copious communications. Semi-trucks cost hundreds of thousands of dollars and are carefully scheduled to make the most of their time. Bringing them in from a wide distribution area and having them out of commission while installs are performed (and drivers trained) is an expensive exercise.

When there are several hundred trucks spread across the United States and Canada, scheduling install teams and trucks to come to install/training centers becomes a variation on the traveling salesman math problem. Minimizing the total cost of lost trucking time, travel costs and staff time is a classic traditional planning problem.

In summary, like most real-world projects, the environment was complex and required using a variety of approaches. The custom software development was in-house and under our control. We used an agile approach with team-led sprints, demos, retrospectives, adaptation etc. The integration with the third-party package software was more of a hybrid approach. There were monthly deliveries based on a backlog we prioritized, but also statements of work and formal change requests.

Finally, the hardware installs and driver training was handled in a traditional, predictive way. Schedules for installs, equipment, and labor were planned and communicated well in advance. We did adjust these plans based on findings from early installs, but traditional, waterfall-style plans have always been amenable to minor adjustments. Software updates were delivered to the trucks over-the-wire as the trucks communicated back to base, so the agile teams could get new versions distributed once the equipment was installed.  

Making Informed Choices
Assessing uncertainty and consensus-gathering needs are important factors in determining the most appropriate approach to use. Thinking first about uncertainty, well-understood, often repeated work (such as building a new Costco store) represents much less uncertainty than rare endeavors such as building an underwater hotel:

Project Uncertainty

If we add to this uncertainty view the dimension of approach focus, we arrive at a framework for assessing project approaches (shown below):

Approach Focus

The “Approach Focus” Y-axis describes if techniques (approaches) are technical, such as creating a work breakdown structure (WBS); or people-focused tasks, such as team decision making or conflict resolution.

Using this framework of project uncertainty and approach focus, we can see that traditional, predictive approaches cover the bottom left quadrant of the graph well. They are great for work we are able to define and provide good process guidance:

Traditional Approach

Agile approaches tackle the problem space from the opposite corner. They are best suited for projects with high degrees of uncertainty and offer good people-based guidance:

Agile Approach

There is a large overlap, too; it represents areas where we could use a traditional approach or an agile approach. Usually, it is recommended to use the approach the stakeholders will be most familiar with. So, if we are running with an agile team, a risk-adjusted backlog and risk burndown chart will likely be an easier sell than traditional risk management approaches. Likewise, if we are in a traditional, formal contracting environment, then statements of work and bills of materials will be accepted more readily than agile alternatives.

Summary
We can use the project environment to help determine which execution approach to use. Obviously, there will be organizational standards and guidelines to be aware of, too. However, even within traditional or agile guidelines, we can tailor our approaches based on uncertainty and task focus.

New project managers should understand that traditional project management has a wealth of process-oriented guidance for well-defined tasks. Likewise, agile offers much for uncertain, high-risk work that focuses on collaboration and people-based tasks.

We should also be aware that real projects are messy, complicated affairs. We often use a combination of approaches at macro and micro levels to try and be successful. It sounds complicated, but it forms the mastery of being a great project manager and is a journey worth pursuing.

[Note: I first wrote and published this article on ProjectManagement.com here]

 


Volunteering: Giving Back That Feels Like Taking

Volunteer 2Volunteering with PMI has many benefits. Not only does it feel good to be giving back to the profession that supports us, but whenever I do it, I learn something new and build useful connections with fellow project practitioners. Add to this the fact you also earn PDUs makes the whole process a win, win, win.

Project management can feel a solitary activity sometimes. Even if you work with large teams and in organizations with many project managers, the unique nature of projects means PMs often have less in common with their peers than other roles.

In a work setting, not all PMs are willing to share their best approaches or secret sauce. Perhaps they feel competition as if their jobs could be replaced if they openly shared what worked for them. There is no such nonsense when interacting with other volunteers. You are automatically in a self-selecting group who have put a higher cause ahead of their sense of self-worth or importance.

I have come to discover that people who seem guarded with advice typically have little to protect, while those who are generous with their experience know the most and prosper more as they educate others. Knowledge and experience are not finite resources to be hoarded; instead, they become more valuable as you share them.

Over the years of volunteering with PMI, I have met many great industry leaders like “Risk Doctor” David Hillson and PMO guru Jack Duggal. They have been generous mentors, and I often learn more in a 10-minute coffee break than days of training or reading. Generally, the quality of people you meet when volunteering is exceptionally high, because they are doing it for intrinsic reasons, not for pay or recognition. It’s the perfect environment or qualifier to find generous, knowledgeable people to network with. By definition of them being there, they are willing and happy to help others.

I have been in the industry long enough now to have people ask me how I got started. I have been asked how I became involved in agile approaches, or a SeminarsWorld instructor, or worked on PMI standards. The answer to each and every one is that I volunteered for something. That led to me meeting some people and then volunteering on something else. Every industry achievement I have I can trace directly to volunteer activities and volunteer contacts.

I half considered keeping this career secret to myself—the fact that the best method for professional development is free and available to everyone. Yet, that would be so anti-volunteerism that I could not.  The fact is, of course, that only people truly in love with project management want to volunteer long term.

Let’s be clear: It is not all rainbows and unicorns. There may be lots of stacking chairs, waiting around and unproductive administrivia—it is not always about discussing the “next big thing.” Also, the payoffs are random in frequency and nature. The odds of meeting your next hiring manager on a conference call or in-person meeting are very slim. Yet, like many things, there is power in showing up—and luck only favors participants.

The good news is that effort and goodwill seem cumulative; who knows when and where something useful will show up. In the meantime, you are doing something useful and even getting PDUs for your time.

There are many ways to volunteer. I used to help at local dinner meetings, but after moving far out of town I find virtual and full-day events easier to participate in. Your local chapter and the PMI.org website have many volunteer opportunities.

One thing I wish I had realized earlier is that you do not have to be an expert—or even experienced on a topic—to take part or be valued. Unlike a work setting (where you are payed a salary and so expected to largely know what to do), volunteering is great for the inexperienced. People are just glad you are there; and in fact, you get most out of working in new areas since most topics come with a free education and you have a bunch of generous individuals around to explain things.

For years, PMI have used the slogan “Good things happen when you get involved”—and it is so true. If you are looking for professional development opportunities for 2019, I strongly suggest you consider volunteering. I acknowledge the gushy nature of this write-up might suggest some insider prompting from PMI to drum up more volunteers; however, this is personal and heartfelt.

As I reflect on 2018, looking at what went well and what not so well, I see an undeniable correlation. This year, like the last 10, my most rewarding work and business connections came out of volunteering. Heck…maybe I am just terrible at capitalizing on regular work (I do have a history of buying high and selling low at most things), but the things that go well seem volunteer related. Confirmation bias? Maybe. But if you have not volunteered before, give it a try…it’s free, and did I mention you get PDUs?

I don’t think this is just me. If anyone else has experienced similar serendipitous benefits from volunteering (at PMI or anywhere else), please share in the comments below.

[This post first appeared on ProjectManagement.com here]