Legacy Advice for Project Managers

“Leave things better than what you found them.”

I don’t know when I first heard someone say that. I suppose it was likely one of my parents. It could have been through one of my Boy Scout leaders or maybe from a nun in one of my youth catechism lessons. It’s one of those age-old axioms that holds a piece of eternal wisdom about how we should go about our journey. It is a little nugget that has never left me.

And now I’m looking at my calendar. It is reminding me that my approach to retirement is getting shorter, which makes me ponder what I am leaving behind for others. Am I leaving this profession better than what I found it?

Some might term this practice of leaving things better than what we found them as the building of legacy. To me that term has always seemed a little void of humility. This is because I have generally viewed those who are capable of leaving legacies as ones who have built up significant resources and influence over the course of their life – those who would be of a character less humble by virtue of their voluminous accomplishments. But I am thinking about this differently now that I am looming at the door of retirement. Perhaps anyone of any stature can leave a legacy.

You see, I subscribe to the idea that we live in a universe where everything and everyone is somehow connected. Maybe it’s just quantum mechanics, which I won’t pretend to understand. But to me it’s obvious that through our actions, and even by merely existing, we can and do have an impact in some way on someone and therefore by association on the course of history. The impact and influence we have had on others is what we hand down and pass along to those coming up behind us. By definition, that is our legacy no matter how seemingly insignificant we may view our contribution to mankind.

And so today I considered that, if I had to narrow it down, what three pieces of advice (elements of my legacy) would I pass along to other project managers? I have thought through what I have learned in text books, what I put into practice based on what I have learned from others, and (maybe more importantly) through the changes I have made from the lessons I have learned. Here they are:

Balance Project Objectives and People

In that project managers are generally task-focused people, it is easy for us to be consumed with checking off a list of completed project objectives. And, because our center is on the completion of things, it’s easy for us to deflate the fact that we are exclusively dependent on imperfect humans, not machines, to do the work of completing these objectives.

Here’s the trick: The project manager who can balance the weight of the demand to produce a high level output with the limitations of humans is the one who has mastered the trade.

Every one of my project teams over the years has had people of various skill levels and output capacity. And nearly every project has had unrealistic delivery expectations. Given this situation, the taskmaster in us would simply demand that no matter the available skills, time, or budget, “just get it done”. Sadly, I have heard this phrase far too often from managers at every level. This demand and approach is infantile. It demonstrates limited management and leadership skills. The good news is that project managers have a much bigger toolbox than this.

Here are a few of the tools that can be applied in these seemingly impossible situations: 1) inspire, influence, motivate, and empathize with team members to do their absolute best work while praising them at every opportunity for the good work they do, 2) use data to show progress to the project sponsor as often as possible and use this information to continually align on team output capability and expectations, and 3) together with other project leaders, generate ideas and formulate the best path forward when projections indicate that an on-time and budget delivery is at risk. The possibilities here are only as limited as the team allows. So, open up the floodgate of ideas and let everyone contribute. Doing these things early and often will pave the way to a favorable ending to any project.

Yes, for any number of reasons, some team members will under-perform. And yes, some project sponsors and other key stakeholders will be unreasonably demanding on the project team. These are times when the project manager earns their title and honors their profession by finding ways of further motivating team members while simultaneously working through ideas with leadership for improving the project outcome. Neglecting or not satisfying either of these will cause an imbalance that may put the project at risk.

We juggle. We balance. We explore. We moderate. We find a way. That’s what we do.

Projects Will Ultimately Fail Without Sincere Buy-in

Too many times I have had project stakeholders at every level tell me they are all-in and then immediately demonstrate that they are not through an underwhelming response or performance.

When participation weakens, interest wanes, or enthusiasm diminishes we know that problems have already set in and we have work to do to bring excitement back to the project.

I look to actions instead of words as my crystal ball for predicting the future of a project. I have watched companies spend millions on halfhearted efforts. Every single one of those projects eventually (maybe not immediately) failed. They failed before the project was initiated (actually, the best case), during project execution (most of them), and even after the final acceptance upon project completion (the most ridiculous case).

If key stakeholders at every level are not fully invested and inspiring others to do the same from the beginning of the project, throughout project execution, and for the duration of the time it takes for the organization to fully adopt the change for which the project was intended, it will very likely put a tick in the failed project column. Note here that some of our most important project work happens even before the project starts.

A software project is a great example. If stakeholders are not convinced of the need for the new software, if they are not interested in participating in configuring the software to meet their needs, or if they are not willing to use the software in the way it was intended to be used, the software project will have been a waste of everyone’s time and money.

My advice here is to gather up whatever influence the project manager has accumulated and use it to entice as many key people as possible to get as involved as possible as early as possible and as often as possible in a way that piques and maintains their sincere buy-in. Before project initiation, if the project idea is not embraced by all key stakeholders, press the pause button, reassess the ‘why’ of the project, and do not proceed until buy-in is secured. And then throughout the project, gather and exercise every idea that helps build and maintain excitement and anticipation. Do this with every project and the result will be a large successful portfolio.

Trust, Not Control, Wins in the End

Project managers who insist on constantly micromanaging their team members and putting in strict controls over every action during project execution will surely lose more respect than gain accomplishments from their team members. Ultimately this kind of management leads to more failed than successful projects and an uptick in the erosion and demotivation of teams across the organization.

Team members have worked hard to become experts in their field, which should gain them well deserved respect from their project managers for what they do best. So, loosen boundaries as much as possible, give every person on the team room to shine, and recognize them individually and publicly when they do. If and when they fall short, speak to them in private to discover why and plan with them the path forward to revive their success.

Of course every project needs controls. But put in only necessary controls that cover critical constraints. Don’t allow controls to prohibit the speed of production, stifle critical contributions, or limit brilliant innovations from team members.

For instance, I have managed projects with highly technical people. Left completely on their own, they tend to over-engineer and over-complicate technical solutions. This is a sign of their expertise, but it can sometimes result in busted time lines and budgets. We need both: excellent work and an on-time and budget ending.

What I have typically done to resolve this is to work side-by-side with the team’s business analyst, technical leads, and key business owners to come up with ways to provide value even if we need to cut back on some requirements while maximizing what can be delivered within the limits on time and budget. This approach creates project co-owners, empowered decision makers, and contributors to the management of project constraints while still giving everyone room to excel at what they do best. At times an executive steering group may need to make some of the decisions or provide direction, but the point is to get all the right talent contributing, completely bought in, and dedicated to the best and final outcome.

By transferring some control and responsibility to every team member, the team becomes single-focused, united, and stronger. They also appreciate that I am not micromanaging the details of their work, that they have been given the respect they have earned, and that they have been given some control and ownership of the project outcome. That is powerful stuff! Everyone is invested, productive, and valued. Together the team wins.

Final Thoughts

As I worked through composing these three pieces of advice, so many other things came to mind. It was difficult to narrow this down. But in my final analysis, as seen weaved through the three items above, the place from where my four decades of projects have succeeded or failed was in the treatment and management of the people who did the work. It was not pressure from the bully executive. It was not in keenly written rules, regulations, procedures, or processes. The longest lasting and greatest contribution to project success in my experience has nearly always stemmed from relationships rooted in hard-earned mutual respect.

I hope these three pieces of advice will help project managers leave things better than we found them. Are they part of my legacy? Maybe. I’ll let others decide that.

The Ultimate Project

In review of my decades of project management work, I cannot think of any project more impactful, meaningful, and worthy than the one I am doing right now: retirement from active full-time employment.

Defining the Project.

It's easy to question whether or not reaching my retirement day is really a project at all, by definition. The Project Management Institute (PMI) suggests that a project is defined by primarily two elements: a temporary endeavor and a specific and unique result.

Since this project was initiated on the first day with my first employer and has spanned more than four decades, it would be a stretch to classify it as a temporary endeavor. As for the other part of the PMI definition, for certain, retirement from active full-time employment fits well in that the effort produces a specific and unique result.

Maybe a better characterization would be that this path to retirement has been a program (a collection of related projects). For instance: selecting and starting retirement investment accounts, achieving employment promotions, becoming debt free, securing a retirement health insurance plan, determining a post-retirement budget, creating an estate plan, having a will drawn up, and the list goes on.

However one wants to define this, it is still an event that takes on all the standard project management processes: initiating, planning, executing, monitoring, controlling, and closing. Or if viewed from an Agile Methodology perspective: it is a massive backlog of tasks that have been refined, prioritized, and accepted into smaller, timeboxed efforts over the course of many years. So, that works too.

The Work Packages / Epics

As of this summer, I will be two years away from that magical date. It is getting exciting around here. Ten years ago it was more conceptual than it was defined. As the ensuing years were marked off the calendar, the vision and objectives became better defined. And now the goals, target date, and preparation steps have all become much more clear.

It seems most people are focused on the financial part of retirement. Securing the financial resources to be able to retire is certainly one of the biggest epics or work packages in any retirement plan. I have been calculating and planning all that since I started working many years ago. I have watched my retirement accounts grow along the way and learned to be patient with the ebb and flow of the markets. But there is more, much more to the plan.

As already mentioned, there are other things to consider: retirement health and long-term care insurance, determining a post-retirement budget, creating an estate plan, updating my will, and so on. These are all necessary administrative chores.

Another set of tasks to consider is preparing for what I will do with my time. To answer this I needed to do some self-examination. I already know that I am not an idle person. I never have been, and I do not want that to change. Sure, I will slow down with age like everyone does, but it is important for both my physical and mental health to keep busy and purposeful. That is the key for maintaining my physical and mental well being while also bringing satisfaction and meaning to this new life I will be living.

No doubt, I will enjoy more time with the grandkids, working in our gardens, taking care of our chickens, hiking, and fishing. But there is no definition of done with any of those. Those are enjoyable and repeatable activities I will do to keep me busy and content. However, I must also participate in activities that offer purpose and meaning, much like I did while I was part of the workforce. And if it can be measured, for me, it will be a bonus.

Many retired people volunteer at an organization that is special to them, or they may take a part time job where they feel like they are contributing to something meaningful. I do not have all that figured out yet, but during the next couple years I will be thinking through and narrowing down all the possibilities and options.

I also realized that activities requiring a good amount of physical activity will need to be done earlier in my retirement while I am still physically capable. I anticipate the same will likely be true about my mental activity. In project management, factors such as physical and mental health, mobility, and location could be risks, assumptions, issues, or dependencies. So, I will start considering those.

Then there is this Bucket List. It is the list of things we want to do before we die. I guess this works for people who need to have a time when it would be OK for them to die. For me, it never made much sense. The date of my death will be unknowable until it happens. Therefore, completing a list of things to do before the unknowable date of my death is, for me, a frantic and likely unachievable proposition. Why would I set my direction toward probable failure in the last leg of my journey here on earth? No thanks.

I will skip the bucket list idea. Instead, especially since my heart surgery twenty years ago and other health issues since then, I have been intentionally trying to live my best life every day - retired or not.

Closing

I am very much looking forward to closing the most impactful, meaningful, and worthy project of my management career. The closing of this project, much like many of the projects I have managed over the past decades, is more like a transition from completing the preparation steps to living and operating in this new space of which I have prepared.

And I am also very sure that after I am retired I will continue to refine and improve what I may have missed or set aside for later. But that is normal and it is all part of the plan. Happy retirement to me!

PM Consultant Basic Spreadsheet

Any project manager who has been around the block a few times knows the old standby tool for managing projects is a spreadsheet. As much as we may try to avoid it, as much as we try to fall in love with the latest new thing, and for as strict as governance may be at the place we work, every PM has a spreadsheet hidden somewhere in their tool kit. Admit it. It’s true. For some project managers, a spreadsheet may even be their only go-to tool for every project.

So what. It’s reasonable. Why? We still use spreadsheets because they are simple, familiar, and we have yet to find a tool that does everything we need it to do in the way we want it. It gets frustrating. So, we turn to the familiar and to our old trusted friend: the spreadsheet.

I’ve worked at many different types of organizations, each had their own set of available or preferred tools. In some places, I was the one setting the standards. Some tools were prescribed (mandatory) and others were suggested. In every case I chose, adopted, or adapted the set of tools that best fit the type of work I was doing to the type of output expected by leadership.

Although the specific tools may have been different, the objective was fundamentally the same: to effectively manage and communicate the status of the project.

Of recent years, I’ve been working for a software-as-a-service consultancy. Delivering software in this type of business means the PM must manage the delivery team in a way that ensures the actual budget burn-down and specific project deliverables are tracking on schedule with baseline expectations defined in the statement of work.

The critical difference between consultancy work and projects internal to a company is that consultancies live and die by their ability to deliver to clients based on stipulations in legal agreements. Your company likely won’t engage attorneys if you don’t deliver your project on time or within the agreed budget. And so, creating and maintaining tight controls on project delivery is more essential for consultancies than in many other types of PM organizations.

For this reason with my current employer, we adopted a centralized tracking system as the source of truth for all project data in our delivery portfolio. The system connects human resource assignments, timesheets, task-time allocations, timelines, milestones, and all project financials (costs, revenue, expenses, margins, purchase orders, invoicing, etc.) together with the ability to report on any aspect of the delivery automatically and in real-time. But it wasn’t always that way. When the company was a baby start-up, this system had not yet been adopted and processes were far less refined. We used...you guessed it: spreadsheets.

Today in this posting I’ve attached a basic spreadsheet that I’ve developed over the years, starting from the early days when I owned a boutique consultancy and through my many consultancy-type employers. It contains tabs for a schedule-gantt, timesheets, baseline to actual budget and resource forecast, RAID, RACI, stakeholder register, change log, and communications plan. It’s not going to do everything for everyone in the way each of us wants it, but it’s a good start at capturing core information needed for consultancy PM work. I hope you can use it and adapt it for your needs.

Link to: Consulting Service Project Tracker 

Efficiency and Change

There is much to-do these days about shifting our focus from operational efficiency to putting more energy toward change management. Proponents of this would argue that efficiency is the enemy of change, meaning that time spent making current processes more efficient takes time away from advancing the business to keep up with market and technology changes. Admittedly, it is difficult to maintain an efficient operation in a continually changing environment. And so for one to embrace this position is not unreasonable. But it doesn't have to be a position that abandons efficiency all together.

In discussions about what is more important - efficiency or change - one could argue that the greater need in today's business environment is being able to change quickly and often. History seems to indicate that operations ran the business in the past when we had slower paced technology advances and production depended greatly on high volume output of less often updated product versions. The game was to get the most production volume with the highest quality in the least amount of time. 

But in today's marketplace where technology is advancing daily and customer demands are unrelenting, those who can change faster, although maybe not as efficiently and even with inferior products, are often the ones leading their industry. Products, inferior or not, have a shorter lifespan now than a generation ago because the next greatest version may already be in production. A generation ago we were only imagining the idea of sending a highly trained astronaut into space with a great number of unknown risks. But now, just this past week, we had untrained civilians in space and plans are already in motion to colonize other planets. How does this volume and speed of change happen without sacrificing efficiency or quality? 

In 1980 time spent in the business was about 75% dedicated to operations and 25% dedicated to projects. Today it's closer to 50/50. A good source of this trend is documented in a recent Harvard Business Review survey. This survey indicated that 85% of professional project managers and executives have seen an increase in the number of projects over the past 5 years, with 25% of them saying their project volume has doubled. We know that most projects deliver change to the organization. With the increasing volume of projects, it is quite evident that change is now beginning to drive the business in a much more influential manner than in the past. 

As mentioned earlier, this trend is partially driven by the advancement of technologies, which has increased speed to production, especially with the use of big data, artificial intelligence, and robotics, which typically reduces defects and requires fewer people - people who tend to present the greatest challenges to efficiency. Most businesses can't afford to ignore this accelerating rate of change; it is significant. 

This doesn't mean, however, that businesses should abandon efforts to become more efficient for the sake of being agile enough to change quickly. Efficiency drives down costs, increases productivity, and improves customer satisfaction. That hasn't changed. 

I challenge anyone to name a successful business that would abandon higher profits and better customer satisfaction for a nice change management program. 

Obviously, it's not good for business to pay no attention to efficiency. But if the changes brought about through projects increase efficiency, it's time to get smart on how to implement change. For instance, when a project introduces a technology that will make us produce more with fewer defects, the business needs to be ready and willing to make the change. The alternative is to lag behind competitors and eventually become irrelevant.

As always, these things are a balancing act. Determining how much time and resources should be diverted away from efforts directly dedicated to efficiency improvement and onto change process improvements is dependent greatly upon the type of business. 

Here are a couple of cases to consider:

Case 1: A service delivery consulting business. If consultants can't be efficient at what they do, it will directly impact margins and ultimately the life of the business. In consulting as in many businesses, time is money. The loser in the consulting sector is the one who delivers lower value at a slower rate. So, efficiency matters here. But it also matters with respect to change because the service industry evolves and must find faster and higher quality ways of delivering if they are to remain competitive. In this case, changes that are introduced must always involve measurable efficiencies, which brings value to the offering. Otherwise, what's the point? In this case one could argue that change is important only if efficiency is an element of the change. 

Case 2: A technology company. Keeping up with the growing demand for continually advancing capabilities should be at the center of the business. The greatest offering in this space is often the ability to change quickly, offering clients the capability to keep up with their industry and market changes. But if the technology changes don't offer efficiencies and value to the client, it's practically useless. In this case one could argue that the ability to change quickly is of greater importance than maintaining higher levels of efficiency. But again, if efficiency isn't part of the offering, the technology would be hard to sell. 

In both these cases, efficiency and change are interrelated. The consulting business must be able to deliver efficiently but must also be able to meet the demands of their customers who are trying to keep up with the swiftly changing marketplace. The technology business must always be pushing changes to the product offering to keep up with customer demands, but the offering must include ways for their customers to become more efficient at what they do; large profit-absorbing inefficiencies for the sake of being the leader in their changing industry could prove catastrophic in the long run. 

It is clear that a balance needs to be reached in every business. Each should consider the needs of the business and the needs of their customers when deciding this balance between efficiency and the ability to change. But be sure that no business can ignore the need to change in this quickly advancing world.

Managing Risk on a Hiking Journey

It’s now day six of my hike on the Arizona Trail, going northbound from the Mexican border along an 800-mile trail. I’ve made great time. Today I’ll pass the 100-mile point a little ahead of schedule.

My right knee, however, is presenting some challenges. Pain shoots through my leg with every step. It’s been building for the past couple days and now it’s beyond the normal ache a person experiences with this kind of activity. I’ve been doing 15-23 miles per day up to this point through the rugged southwest desert. Ibuprofen helps hide the pain, but I fear this may be an injury that demands more than just medication.

The planning for this hike started several months ago. I have spreadsheets with details about meals, gear, elevation gain, and mileage for each day. There are buffers and contingencies in the plan for weather occurrences and potential injury incidence. The critical path is the actual path through the wilderness, combined with resupply points for food and other perishables. I had only 10 days to give to the trail, which would put me at the 165-mile point, averaging 17 miles per day. Since I’m a project manager for a living, putting together a successful plan for this kind of activity is a natural fit for me.

The contingency plans for injuries identified bail-out points for any non-debilitating injury. This would provide a safe means for getting help if needed. For any injury that left me unable to walk I would use my emergency device to call in search and rescue. The seriousness of the injury will dictate the impact on the schedule and scope of the hike and would be managed on a case-by-case basis.

At the start of day 6 my position on the trail put me at 16 miles to the next potential bail-out point. There were several other options further up the trail, but none of them presented the same opportunity. This next bail-out point had immediate access to a busy state road, where I could quickly get help or a ride if needed. Whereas, options further up the trail were less trafficked forest service roads, which may delay help for hours or even days.

What are my next steps? How can we handle risk management in this situation?

First, identify the seriousness of the situation.

This hike has a timeline constraint with a defined trail-length goal. Best case is that the pain in my knee would just slow me down but allow me to finish on time. However, my condition was not trending toward improvement. Worst case is that I am developing a serious injury that may increase the need and urgency for medical help if I continued past this next bail-out point.

Second, perform a risk assessment and identify risk reduction options. (populate the risk register)

The risk to a serious knee injury increases with distance and physical stress on the knee. Completing the entire 165 miles is the desired goal, but not necessary. If I continue past the next bail-out point, the probability of the knee worsening is high, and the impact of a worsened condition is high. I’m also operating in a cloud of uncertainty; the certainty of the knee’s medical/physical condition is unknowable without an assessment from a medical professional. The options are 1) to bail out at the next opportunity to get a physician’s diagnosis and potentially prevent a debilitating injury, 2) move on to the next bail out and reassess again at each bailout opportunity, 3) make camp and rest a day before deciding.

Third, decide on a plan of action.

No doubt, continuing to hike without seeking a physician’s opinion presents a high risk both to the body and to the hiking (project) objective. The hiking objective of 165 miles is not a hard requirement. Less distance, although not the most desired, does not mean a failed objective (we’ll call it ‘limited success’). The path of least risk seems to be option 1. Bail out at the next opportunity to either get a physician’s diagnosis and/or to stop the hike and take whatever time is required for recovery. Option 2 is one to delay a decision with very possibly increasing risk. Option 3 defies the current trend; the knee is worsening; it doesn’t seem that one day of rest would allow me to finish in less pain or at all. Expert judgement is a valuable technique in this case.

Let’s also run through a more complete risk management overview.

Plan for Risk Management

We have a plan that was informed through our understanding of the environmental factors (weather, trail conditions, physical demands, etc.), data from analytical techniques, and injected expert judgement.

Perform Qualitative and Quantitative Risk Analysis

Our risk management plan included contingent bail out points, associated costs, schedule impacts, data gathering, modeling our change options, scope assessment, probability and impact matrix, and an urgency assessment.

Plan for Risk Responses

We’ve developed strategies for each change option to lessen the impact of the risk and measured these strategies against the plan.

Control Risk

We’ve considered performance data, measured and projected outcomes based on an audit of different change options, and injected all these inputs early in the process as to allow time for adequate assessments and decision making.

What was final the outcome?

I decided to bail out at the next opportunity and end my hike. This choice curtailed serious injury, avoided a costly medical situation, and satisfied two thirds of the project objective. I will have another opportunity next year to continue this hike.

What Have I Done with My Life?

Any project manager who hasn’t been hiding under a rock in recent years knows about Agile Methodologies. One common way of delivering this methodology is through Scrum, where one will discover prescribed activities called “ceremonies”.  One of these ceremonies is a retrospective. This is where the delivery team meets to have a candid discussion about what was done well and what wasn’t. The objective is to find ways to improve how the team functions and produces. This ceremony helps the team finish the project with a little respect. Simple.

If only life were like Scrum. Right?

Well, it is.

A project is often defined as a temporary effort to create a unique result. Coincidently, this also accurately defines my life. I definitely am unique. I’ve been reminded all too often that I’m only temporary. And to be remembered as one who made a difference, who produced something positive, is the end game.

So, there you have it; I’m a project. Now all I need is a methodology to help me get to that glorious end. Enter Scrum.

On occasion I think back, and I think forward, and I wonder. I wonder about how I’ll complete this project that I am with a little respect. To help me out, it seems that adopting this Scrum retrospective ceremony would be worth a try. Here we go.

Part one: what have I done well?

I want to believe I’m balanced. Sometimes I’m too critical of myself. Sometimes I’m the most confident expert on my own opinion. But how could I possibly have an unbiased opinion about any good I may have done? It may be best to turn to others for their input. But don’t think you’ll get the answer here in this article. This is more about how to arrive at the answer in the title, not about me. Try not to be disappointed.

When working a project, look to the team to recognize what the team has done well together. If you frame the question in that way, you will more likely receive input that recognizes and builds upon teamwork. This is the best kind of work, in my opinion. To kick off the discussion you may offer a fill-in-the-blank statement: I think the team did well when we [did what?] which resulted in [the positive output].

You might also ask the team to recognize other individual’s good actions. But when you do this, focus on actual results, not feelings. You won’t find a feeling listed as a Statement of Work deliverable. If Johnny did something great, focus on how that great thing contributed to a positive, tangible result. This will reinforce and encourage actual behavior that produces results. The statement might be: When [person’s name] did [action] his actions resulted in (or contributed greatly to) [this deliverable for the project].

Use the same approach in your self-project. No one is an island; we’re all connected. Many, MANY people have contributed to who I am and many more will contribute to who I will become. But don’t dismiss your own contribution. Everyone contributes. Everyone counts. Be generous to yourself as well as to those who helped you along the way.

Second part: what have I done that didn’t go well?

If you’re expecting me to answer this question here, you’re aiming too high. But I will say this: a little introspection will go a long way in this retrospective exercise.

The part of me that is too critical of myself shines bright here. But let’s not get too carried away. Recognition without criticism is the way to go. Recognize the problem, examine the reasons, then formulate a corrective action for each reason. Fix the root cause and you’ve eliminated the problem.

On the project, this is a good time to de-personalize things by asking what the team did not do well. Stay focused on actual results. Rarely is one person the sole cause of a problem within a team trying to accomplish a goal. It takes a team to be successful. It takes a team to fail.

Another good piece of advice is about the approach. Identifying a problem without a potential solution is just empty criticism. A former boss would tell us not to come to him with a problem if we didn’t also suggest with a way to fix it. Take that advice. Apply it here.

A retrospective ceremony is a good time to let the guard down, be super honest, and set your purpose on finding ways to become better. Take the person out of the equation. It’s not the best time to have harsh criticism of others. Fix yourself on the behavior not the person.

It’s also a good time to do a little self-examination of your own performance. Looking inward is the best way of finding ways to improve what is outward. It’s been said, real change comes from within.

All this can be equally applied to our self-project. It’s better to think about what I can control in myself, rather than finding fault in others, of which we have little actual ability to control or change.

There you have it. A little retrospective ceremony is a great way to continually improve your team and yourself.

What have I done with my life? It’s been a process. I’ve done some good, and some not so good. But with some retrospective ceremonies it’s bound to get better.

Applying the Hawthorne Effect in Project Management

The Hawthorne Effect suggests that individuals will temporarily and generally become more productive when they know they are being observed.

One example of this is when I invite someone of influence, like a VP, to participate in a work session with my project team. Team members who normally pay less attention (read: multi-task) become visibly more attentive and alert, at least for the period this VP is present.

The original Hawthorne research concluded that productivity is strongly affected by relationships and social structure within an organization. Relationships and social structures are very complex, and so this post won’t attempt to do any type of critical analysis about how all that works. Instead, let’s look at something simple. How can a project manager use these powerful relational influences to make a project more successful? I have several suggestions.

Make assignments public and review progress in a group setting. This is a soft but direct way of creating expectations and making individual team members accountable to the entire team. If we know we’re being watched by the team and we are anticipating a public self-report on task progress, we tend to want to report positive results and to show the team that we are pulling our weight. Therefore, we tend to be more intentional about our work to accomplish that good result.

Establish and encourage individual relationships. Friends will do things for friends. It follows, then, that if there are strong personal relationships between team members, productivity could increase. When team members have personal bonds, they produce because they are doing things for each other. How do we create this? I do two things:

1) I become vulnerable. To set the example, I put myself out there. I take opportunities to talk one-on-one with team members about personal things (but not too personal), like something fun I did with a family member last weekend, or I might drop a hint about how my heart surgery has helped me better understand how to balance my time away from work. Don’t reveal everything, just say enough to tease the other person into asking questions or to encourage reciprocal vulnerability. This informs a safe space for each person and demonstrates a supporting environment. But, don’t force this type of openness, and don’t make it awkward for anyone – and please don’t break any HR rules! It should happen organically in the course of normal conversation. Understand that some people are more guarded than others, and that’s perfectly fine. I believe that it’s my job to take the first step in creating a safe and open workspace. Being a “real” person is vital to how this production machine works.

2) I encourage team members to work together one-on-one. When I have a project issue that needs to be solved and there are several people who hold key elements in the resolution, I often ask them to get on the phone or meet in person to collaborate on the solution. This shifts the responsibility and reward for solutioning and idea generation to team members. This is a powerful tool on project teams. It helps create ownership and forms a strong, supportive, and collaborative community within the team.

Take time to recognize and appreciate everyone’s work. Usually several times during each project I will send a personal note to each team member letting them know how glad I am for their contribution. This is most conveniently done when they complete a task – but it’s not the most powerful time to do this. The most powerful time is when it is spontaneous. It can be added as a side note in any other exchange. Sometimes I’ll stick in a “By the way, you’re doing great! We’re almost to the end thanks to you!” type of message. It doesn’t need to be wordy or overstated, and it shouldn’t be done so often that it loses potency. Sometimes I’ll introduce team members as my “Superstar of [fill in the blank specialty]”. These kinds of messages let each person know that you and others are watching them. Encouraging words are remembered and they help empower team members through the tougher times in a project.

The timing and the delivery of these suggestions is also important. Note that the Hawthorne Effect normally has a short lifespan. People tend to default back to their “normal” output level not long after they feel they are not being observed anymore. This means that project managers need to be mindful about when to engage various techniques that encourage stronger production.

It is also important to be watchful for signs of burnout. I like to say that the smart ones are the first ones to leave; which, will likely happen if people are made to work at maximum capacity for long periods without breaks. We don't want our best people walking.

And above all, be genuine. People become wise to fake and insincere statements or attempts at relationship building.

The next time you are looking for a little boost in production from your project team, consider ways to invoke the Hawthorne Effect.