Handling “Crazy” Project Ideas with Class

Once I was supporting a project that lasted about 18 months. About a month away from the project deadline, I was feeling proud that I’d built trust with a new team on this project and led them through all the required decisions in a timely fashion. Most of the big project deliverables were nearing completion; only small decisions and details were left. We had plenty of buffer time and breathing room.

I felt pleased and relieved.

…for a moment.

The next moment, I felt a bit of panic.

Because I remembered what tends to happen when everything winds down and people finally have time and space to relax…and think…of NEW IDEAS. New ideas that feel like the best ideas ever, and we should rush to fit them into the project before the end, even if we don’t have time to explore and execute the ideas in a calm manner—even if this means we now need to ask our teams to scramble to add the extras.

I worked so hard to achieve this calm at the end of the project, and I had a nagging suspicion somebody was going to ruin it with a “brilliant” new idea.

Lo and behold, not an hour later, I got an email.

One of our event presenters wanted to add a hands-on demonstration to his presentation. He wanted us to order new products with gift packaging for every attendee, as well as capture the moment of the demonstration on camera and video and, if possible, live stream it from a drone.

Deep breaths. Lots of deep breaths.

This isn’t a fun moment for a project manager. We work so hard for things to go smoothly, and sometimes we’re thrown a curveball request anyway.

The good news is that even though complex, curveball, or last-minute ideas are uncomfortable, project managers still have the tools to handle and address these ideas well—and even to do so with class, poise, and confidence. I’ll show you how.

Take all ideas seriously.

Despite the title of this blog post, let me clarify that I don’t think my colleague’s idea above—or any extreme-sounding idea—is crazy.

It might feel that way when you first hear it, and you should take a moment and have your feelings. But after you’ve calmed yourself, keep a few things in mind:

• This is a person with good intentions who means well. Whether the idea is good or bad, feasible or not feasible, the person with the idea wants to make the project better. That’s a good thing! Approach them on those grounds, not like they’re crazy. Wouldn’t you want the same if you were excited about an idea? Wouldn’t you want other people to see your good intentions, and ultimately let you down easy if your idea wasn’t going to work out?
• Is it our job to have smooth projects, or successful projects? It’s easy for a project manager to have a bias for smooth projects—I certainly do. It’s more comfortable for me to have a “done” project than a “good” project. But as frustrating as it can be to field complex or poorly-timed ideas, they could improve project results, so it’s our job to put the appropriate time and effort into them on those grounds. Not excessive time and effort, but appropriate.

If the person has good intentions, set your reactions aside, take the person and their idea seriously, and honestly explore whether the idea represents a worthwhile improvement to your project.

I can only think of one exception to my recommendation to take all ideas seriously: if you’re on the receiving end of too many ideas, and you only have time to address the most promising ideas if you’re also going to keep the overall project on track. Then I could see ignoring the less-promising, less-feasible ideas—not criticizing them, but just letting them fall by the wayside.

In the situation above, I started by replying to the email that I’d give some thought to the first steps on exploring his idea, and I’d get back to him soon. Then I got to work figuring out what those first steps should be.

Lean on existing change processes.

Depending on your setting, you might have the steps for fielding new ideas for existing projects already outlined for you—which is usually a good thing, especially when your personal feelings might cloud your approach to an idea.

The formal terms for steps/tools like these are change requests and change control processes.

A new idea for an existing project is really just a proposed project change. At a company with formal change control processes, often anybody can submit a change request, but the people who must review it and give input are clearly defined for a given project or department. For a particularly big and formal project, there might be a change control board—a group of people that reviews all change requests for a given project and gives responses such as “approved,” “rejected,” or “approved with modifications.”

In a setting like this, your response to a surprise idea can simply be, “Great! Feel free to put that idea in a change request. The team will review it and get back to you!”

If you support agile projects, change is built more naturally into project processes: the idea can get added to the product backlog as a user story, or to the list of potential tasks for the team or product owner to review at the next established time to review and plan a new increment of work.

Even if your company’s process for fielding proposed changes is not as well-defined as either of these scenarios, there may still be some guidance in place. At my company, each project has an “owner” who is responsible for day-to-day decisions, and a “sponsor” who the owner contacts if an issue or change is big enough. Therefore, I knew a major component of addressing the new idea on my project would be to place it before the two project co-owners who would decide if it should move forward or not.

Do you lack any clear process for dealing with project change, or do the existing processes have gaps? Then you’ll likely need to use old-fashioned interpersonal and negotiation skills to get a decision made about this change on this project. But be sure to take notes and write down your ideas about what change processes would be helpful, and seek to get them implemented before you’re in this situation the next time! They do not need to be overly formal, just a good fit for your particular teams and projects. Your future self (and future project managers at your company) will thank you.

Address the idea on its own merits.

There’s one more thing that will help you in this scenario, and that’s the idea itself. If your initial reaction to the idea is not good, that reaction is based on something. Calling the idea “bad” isn’t very helpful, but you probably feel the idea is “too” something: too expensive, too difficult, too amateur, too much work for the time remaining, etc.

If your initial reaction to the idea is valid, this should be a self-evident part of the idea that will rise to the surface as the idea is reviewed and considered by the appropriate people. Basically, you shouldn’t have to say to the team, “Here’s a terrible idea; please reject it.” You should be able to say, “Here’s an idea; here are the pros and cons that have been explored; what should we do?” And if the cons outweigh the pros, the decision-makers will be able to see that, and the idea will die. But if the pros outweigh the cons, the idea will move forward as it should, and your reactions didn’t get in the way.

Leaving your feelings out of this process is respectful to the person with the idea, and should be at least as effective as sharing your feelings would be—if not more so because you’re not creating new team tensions that need to be ironed out later. Make it easier on yourself.

In the hands-on demonstration idea on my project, I started by exploring the ‘live stream from a drone’ part of the idea because I knew it would be the most challenging. By talking to somebody with drone experience, I was able to identify a few significant drawbacks and limitations quickly. I shared these with the presenter, who agreed the obstacles were too great and we shouldn’t pursue live streaming from a drone after all.

Then I set up a meeting for the presenter to share the remaining parts of his idea with the project owners for their consideration. They approved the idea, and we proceeded with a few more feasibility discussions, followed by execution.

I was pleased with how quickly I managed to shepherd the situation from “oh wow, that’s quite an idea” to a calm execution that everyone understood and was happy with, in a way that was respectful to everyone involved. This is achievable with your “crazy” project ideas too, if you take people and ideas seriously, use change processes that are already in place, and give the idea room to stand or fall on its own merits.