What to Do When There’s Nothing to Do

Whether or not you’re ever in this situation probably depends a lot on the size of your own personal project portfolio and how your company handles projects. It’s happened to me a few times, but it’s not a constant.

Here’s the scenario I’m talking about…. You have a lot of projects on your plate. For me, when it happened the most is when I had maybe 12-15 projects on my radar at any given time. 4-5 of those projects would be very active – moving ahead full steam. Another 4-5 of those projects would be moving along slowly – possibly experiencing some sort of delay but moving along never-the-less. And then there would be a final list of 4-5 projects that seemed dead in the water but promising to jumpstart as soon as one of the following happens:

• Customer funding kicks in
• Customer agrees with the price or estimate (depending on whether it’s an external or internal project)
• The right internal delivery resource becomes available (really only applies to internal projects – you can’t hold an external customer up for an internal resource…you’ll be out of business)
• The customer is waiting on the right customer-side resources to staff the project
• Did I already mention funding? (the most common reason a project – especially internal – would get stalled to the point of death or near death)

For the purpose of this article, I want to look at those 8-10 projects that aren’t moving along – or are moving along at such a slow pace they’re like the rotating bar atop the Peachtree Plaza in Atlanta – you’re trying to figure out which part is actually moving but you can’t because it’s all moving too slow. Ok, maybe I had consumed one too many drinks and I was sitting with the future runner-up to Miss America, but it was a long time ago and I was in college.

Staying on Top of Things

So how can we keep track of those nearly dead or slow moving projects? Well, we don’t need to keep track of them so much as we just need to stay in touch with them. It’s easy to let them fall away because we’re swamped trying to ensure the success of the 4-5 projects that are hot. But we can’t overlook these other projects. They still need care and feeding…the customers still need us to reach out to them – they need to know we’re still in the game and ready to kick things off again when they’re ready or when whatever is holding things up is lifted.

Here’s a few ways we can make sure we’re still in sync with our customers and our teams for each these stalled projects project:

• Maintain weekly contact with the customer – no status reports, but a call or quick face-to-face (depending on logistics) to share any updates, etc.
• Weekly communication with delivery team resources assigned to your ‘on hold’ projects to provide any updates, ensure they’re still ready and available if and when the project starts up again
• Regular communication with your delivery team resources’ direct managers to keep them up-to-date on status – if your currently assigned resources are going to be assigned elsewhere, then you need to know you can get skilled replacements fast if things start up quickly and the only way to do that is to keep managers informed
• Regular updates to the PMO Director (if applicable) so they are aware of the status of each stalled project and can make adjustments to your work project assignments accordingly

Summary

In reality, there’s usually little you can do for a project that is stalled or on what seems like permanent hold. What you can do as the Project Manager in charge is maintain regular contact with the customer or project sponsor to let them know you’re still out there, ready and waiting. Sometimes that will help jar a project loose to get it started again, but it will also keep you in front of the customer when the current stalled project restarts and hopefully will move more engagements from that customer your way.

Project Management: The Art of Keeping it Real

The Formal Stuff

We do a lot of ‘formal’ things on the projects we manage. Hopefully, if we’re good project managers following a reliable ‘process’, then we hold meetings, deliver status reports, track issues and risks, forecast resources and costs and have a detailed project plan up-to-date every week if not every day.

We can formally project manage our butts off and still not have a successful project. Sometimes there’s nothing that can be done about that. Things go wrong, technology fails us, team members let the project down, executive management cans a project, or even the customer changes their direction and it just doesn’t meet their needs anymore.

However, there are times when things that make a project unsuccessful are very much within our control. If we’re not managing the project well, that can be one of those instances in our control. But I’m writing this with assumption that we are doing the right ‘formal’ things on the project as stated in the first paragraph above. What I’m talking about here is the little things. The things that make or break customer satisfaction, team satisfaction, and even CEO satisfaction and help ensure our project’s success – or kill it.

The Extra Effort

Some of the things we can do – the more intrinsic things on a project that keep people happy, involved and focused are:

• Frequent communication with the customer well beyond the required weekly formal calls and reporting
• Understanding customer concerns and offering expert advice and possibly additional skilled project resources to address questions and concerns
• Frequent adhoc discussions with our delivery team as a whole to keep everyone focused and engaged and make sure where all aware of the key tasks and assignments at any given time
• Frequent adhoc discussions individually with our delivery team members to dive into any project, professional or even personal concerns or frustrations they are encountering (don’t let anything build up – it’s never a good thing)
• Especially for very visible, large projects – frequent communication with and updates to executive management
• Invite the CEO or other executive management to sit in on a weekly customer status call – it will inform them, make the customer know just how important they are, and let your team know how valuable this project is and how important they are to it’s success

Summary

There’s more we can do, I’m sure. The key thing to take away from this is that just following formal processes is not always enough. It usually isn’t enough – especially on larger and longer engagements where team members can stray, become exhausted or unfocused, feel unappreciated, or the customer can feel like they are being taken for granted. You’re the Project Manager – keeping everyone engaged and satisfied is not easy, but it’s your responsibility and ultimately increases your chances for success.

We Learn from What We Screw Up

The title basically says it all. We go to school, we go to training classes, we join associations, we read books. We do everything good little IT and business people should do to better ourselves in our profession. And, at the end of the day, we’ve learned some things that help us in our jobs.

But what do we really learn the most from? Growing up, did you learn more from what you were told to do or did you learn more from what you did wrong and had to pay the consequences for? I contend that the latter wins hands-down. It’s nice to learn things…it always is. But when we screw up really good and pay some sort of price for it…I contend that those are the times that we really really LEARN.

Example #1

Case in point…. I’ve mentioned many times how budgeting issues can torpedo projects and I’ve had at least one major project of mine go south due to budget handling issues. I’ve passed blame somewhat, but overall I’m the Project Manager and that’s my responsibility. That which does not kill us makes us stronger, right? I firmly believe that. And that which does not get us fired makes us a better employee, a better server of our customer, a better business professional.

One major project completely shutdown for budget issues that could have been avoided – or least the blow could have been softened – with the appropriate action. I learned from that mistake and budget information is key to weekly discussions and project status reports that I have with and share with the customer now. It’s formally documented – both current budget and forecasted budget – and discussed formally every week. I’ve taken away the question marks and made it a joint effort with the customer. And believe me, the customer always appreciates the knowledge and would rather know the bad things and work through them with you then to waste money and cancel an engagement. I’m certain of that.

Example #2

I also worked on a major $50 million program for the US Department of Education. It was much more of a program than a project – it had a five-year run followed by an RFP process and our proposal and another contract win. The company I worked for always won it because the program had grown to such a large size, it was so complex and had so many add-ons that no potential bidder could knock us – the incumbent – out of contention for the next proposal. We had become fat and overconfident.

Then one day a funny thing happened. We missed a major milestone deliverable. Then we missed another. Then we improperly tested a change order resulting in delays and re-work. Suddenly, the government was not so enamored with our performance and certainly had lost confidence in our ability to deliver. We desperately needed to learn from this mistake, act aggressively and right the ship before it was too late – because at this point the project was within one year of coming up for re-bid.

I had responsibility on this program for all financials and budgeting, all change management, all change orders, disaster recovery, and status reporting. Production was not in my scope, but I pulled my direct reports together and we resurrected the project schedule that I had put together 3 years prior in order to win the current contract and we updated it to what was happening today. What my team and I turned out was a project schedule encompassing nearly 4,000 tasks and a my peer managers on the program were ready, willing and equipped to manage their specific portions of this mammoth project schedule.

My responsibility was to bring that all together and take over leading the weekly status meetings with the government managing everything to that schedule and producing meaningful alert reports from it both for internal purposes and for the customer to hold us accountable to. What resulted was a project that quickly got back on track, a customer whose satisfaction was raised beyond the level it had been previously and another huge contract win down the road. It wasn’t my doing – my entire team and I took the initial action – but everyone pulled together and made it work. We learned from our overconfidence and mistakes before it was too late. And in this case too late could have meant losing our jobs in a year if the contract was lost.

Summary

We’re human…we’re told what to do from the time we’re born till the time we die from someone or another. It doesn’t matter if we’re John Doe or Donald Trump…someone somewhere is instructing us off and on. We learn from those instructions. But I believe we also learn very fast – maybe faster – when we screw up and suffer the consequences. Sometimes we have to fail to perform better.

Should We Give the Customer What They Want?

I think I’ve touched on this before, but it is a topic that deserves more mention. If you follow a traditional project management process, then you expect that the customer comes into an engagement with some requirements in place, correct? And we assume that the customer basically knows what they want. In reality, we need to be very careful what we assume. In fact, it’s better to assume nothing…because at the end of the day if it’s wrong, it will come back to the Project Manager.

Moving Forward

Back to the original process discussion. We have those initial customer requirements in hand. We take those requirements – we assume they are correct – and we meet with the customer to build on them. We come out of what I like to call the Exploration phase with detailed requirements nailed down – or so we think. At the completion of the Exploration phase we have a Business Requirements Document (BRD) signed, sealed and delivered to the customer and another milestone checked off.

We then move on to Design and Development, all the while designing and writing code to match the requirements – and modifying as the requirements change and they ALWAYS change. We Test, we Train, we Deploy….we smile about a job well done and we turn the system on and hand it to the end user and they’re happy, right? Well…not always. How is that possible? We built to the requirements, we worked with the customer project team every step of the way. We delivered what they documented they wanted.

What vs. Why

Here’s the problem. We did a lot of asking the customer ‘what’ they wanted, but we may have never asked the customer ‘why’ they wanted it. Remember, we’re the experts, we’re the consultants, we’re the professionals who have designed and developed and implemented this software solution in some form or another over and over again. We’ve seen it implemented in many industries across the country. The customer, on the other hand, only knows their business…their own business process. When it’s said that way it’s easy to understand how they could have blinders on, isn’t it? Likewise, it’s easy to understand, from our own business and project experiences how you can go down a path for a while and if you go down it long enough you think that is the only way you can or should go. Again, you have blinders on.

We’re the pros – it’s our responsibility to take the blinders off the customer. We need to ask the tough questions. That starts by taking the time up front to understand the customer’s business, their business processes that they’ve mapped out and to understand how those mapped out business processes and the few high-level requirements that they entered the engagement with match up with the solution we can offer them.

A deep analysis with the customer on the ‘why’ instead of the ‘what’ can have a negative result that we have to be prepared for. It can lead to the customer skipping the engagement altogether if they realize this isn’t the right solution for them. If that happens, it happens. But it’s more likely that the analysis can be geared to an even better – and possibly more profitable for us – solution for the customer that provides them with even greater satisfaction and usability at the end of the engagement.

Summary

Don’t assume your customer knows exactly what they want. They rarely know exactly what they want and sometimes they’ll even tell you “here are my processes – tell me what I need.” I’ve had that happen many times – it’s a great way to start an engagement, a nice way to increase revenue, and immediate opportunity to gain customer faith, confidence and satisfaction. It just requires and understanding that the initial project plan likely needs to be extended and the budget for the project may need to grow to accommodate the additional consulting and analysis required.

But even if they don’t ask that of you, you still need to be prepared – always – to ask ‘why.’ If they know why, then that’s half the battle. But likely your questions will intrigue them and you’ll gain some new perspectives, better project information and start the engagement off on the right foot by heading down the path that best serves the customer in the long run.

Run Away! (And Other Helpful Advice For A Career in Project Management)

Run Away! by Cirofono via Flickr

I am passionate about project management in general, and helping people new to the field more specifically.

But let’s be honest. We’re all nuts.

Not Everyone Should Be a Project Manager

There is a specific form of gluttony for punishment that comes with the territory (some consider it a clinical condition). The decision to head down the project manager career path should not be taken lightly.

When I started out, there was a specific resonance I felt as I learned more about the role of a project manager. Everything I had really enjoyed about my previous positions seemed to be a part of this crazy thing called project management.

“You’ve got to ask yourself one question: ‘Do I feel lucky?’ Well, do ya punk?” – Dirty Harry (1971)

Hmmmm….actually I’m going to ask 2 questions instead. And maybe some sub-questions…what the heck. Being a contrarian is just part of my personality… though, it’s not a “desired skill” for project managers. Especially not when you are contradicting a quote you picked yourself like I just did. See what project manager employment does to you after awhile? Koo Koo…Koo Koo

Do You Fit In?

Those shiny, flashy careers in project management may seem inviting, but do you really have a passion for this kind of work? Does your personality lend itself to the type of work?

Do you like working with people? I don’t mean like social work, (although I might have something there) I mean being able to relay technical concepts to business people and get geeks excited about what upper management wants. You need to understand “Projects are about humans,” as the Project Shrink says. The importance of communication in project management has become a cliché, but nonetheless, it’s true. You need to do it effectively and fearlessly.

Are you passionate about this stuff? I really enjoy the process of creating something that never existed before. Even if it is not a tangible, physical product it is very rewarding for me to be able to think about what we did as a team. I love process improvement and change. That’s one reason why out of the various project management careers out there (project manager, business analyst, project controller, program manager, etc.) I chose to be a project manager.

Do You Like Challenge? (Glutton for Punishment Helps)

One of the great things about project management is that at least once a week someone starts running around the place wildly yelling “My hair is on fire! My hair is on fire! My hair is on fire!”

Seriously though, I can’t even smell burnt hair anymore.

Do you like thinking about a project from every possible angle? Because that is what you will need to do in order to be effective. The customer, the team, the sponsor, external stakeholders…they all have to be happy. You need to be able to change shoes every 10 minutes or so. The nature of projects is changing requirements and approaches as you go, so there will always be situations where you are the hostage negotiator that has to make everyone come out alive and feeling happy.

Do you thrive on change? The idea that a project plan is finalized and then very little changes from there is a fantasy… a theoretical construct that only lives in the pages of your project management textbook.

This doesn’t mean you throw your hands up in the air and let chaos rule… but it does mean that effective change management needs to be a key strength. Uncertainty and change happen, and it is all in how you deal with it (and anticipate it) that makes the difference.

What other questions should someone ask themselves before jumping into the alligator pit?

Who Is Josh Nankivel?

I am the founder of pmStudent.com, a site dedicated to helping new and aspiring project managers succeed.

Learn more about your project manager career path right now with my free eBook and newsletter!