Follow this five-step outline to ensure you get business leaders to give your project the green light.
Even if you’re the fastest, most efficient IT manager in the world, there’s only so much you can do. How many times have you had a great idea, but just couldn’t get the funding to make it happen? Even the best idea will fail without adequate resources. As a project leader, one of your most important tasks is to ensure you’re able to secure adequate funding and staffing to get the job done.
The problem is that most engineers think about building stuff, not funding stuff. So to get your project funded, you have to think a little differently. Here are five tips that will ensure the decision makers at your company say yes to your project.
One of the most important parts of being a project leader is making sure decision makers care about your project. While everyone appreciates cool “science projects,” there’s generally limited funding that has to be allocated to projects that solve tangible business problems or generate tangible value.
Engineers tend to discuss proposals in terms of the extent of innovation or difficult problems solved. After all, that was the hard part, right? Unfortunately, this isn’t the best way to sell a project. When discussing a proposal, lead with the value, not the innovation.
Start with a discussion of the untapped market your company is missing, how much money your company could make, or how inefficient a current business processes is and how that’s affecting the company’s value. Start the conversation by creating a feeling of, “if only there were a solution.” Then when you talk about your proposal, position it as the best answer to the situation. While it may sound depressing, think of it like this: No one really cares about your code, your new application or new hardware—they care about what it does.
Engineers frequently complain about how “stupid” other people are, or that the business unit leaders just don’t get it. Interestingly, almost all engineers think they’re smarter than almost all other engineers, so at least half of us are wrong on that front. Part of the problem is that once you immerse yourself in a problem and come up with a solution, you forget about how much time was spent going down the wrong paths until you got your brain to frame the problem in just the right way that a solution presented itself.
The reason engineers get frustrated that other people “don’t get it” at first is often because they forget others haven’t had a chance to go through the thinking and problem-solving process. So when you explain your proposal, leave nothing to the imagination. Create PowerPoint slides or wireframes or documentation that explain all of the key components of your idea.
If yours is a UX project, do your best to create a wireframe walk-through. If your project has client or server components, do a block diagram of the whole system. If your project requires a database of information, make sure to clearly explain how that data will be collected.
While you may not be able to do a full specification, go into as much granularity as you can so you paint a rough sketch of the whole picture. Leave nothing to the imagination, and you’ll ensure that people “get it.” This will help the people who will eventually be funding your project have a full understanding of how your proposal will do what you claim it will.
Remember the phrase “code is king.” People value working code disproportionately more than explanations of what the finished project will accomplish. There are a lot of factors at work here. In some ways giving a project the green light is a leap of faith that something can be done.
Having a working concept can be the proof of existence that gets people to say yes in the first place. It also demonstrates you have a commitment to the project and some skin in the game because you’ve obviously already spent resources (either your own or one of your team members’) to get the project started. It also plays into the “leave nothing to the imagination” tactic, because you have something tangible to demonstrate.
Once you have something up and running, you can start adding features and functions. You can help it grow and build momentum while you work on getting additional resources. Many big projects started out as side projects with people donating their time. So do whatever it takes to get something bootstrapped and working, and you’ll be on your way to success.
When you give your proposal a name—or even a code name—it serves a few purposes. First, it gives your project an additional level of credibility. After all, if something has a name, it must have some value. Second, it helps people discuss it in more concrete terms.
It’s much easier to discuss something with a name than to discuss a concept. A concept could be anything, but a named object refers to a specific thing. Give your proposal a code name and refer to it by name. If you get people excited about it, and you have something bootstrapped, it makes it much easier for management to say, “Let’s approve project X.”
Woody Allen once said 80 percent of success is simply showing up, and so it goes with the whole project-proposal process. If you think the decision makers at your company are looking around trying to determine to whom they should allocate more resources, think again. Usually what happens is they’re trying to decide between 10 people who have already asked for resources. If you haven’t asked, you won’t get a positive answer.
Simply asking will dramatically increase your odds of getting project approval. Don’t be afraid if the answer is no. If the initial response is negative, ask for feedback. You’ll probably find they’re either not excited about the idea or they don’t understand it—or they’re concerned it won’t work. In any case, you’ll have your marching orders.
If the initial response is no, think about these five tips and go back to the drawing board. Don’t be discouraged if you don’t get it right the first time. You’re an engineer. Learning how to be a proposal presenter may be new to you. Take the feedback, diagnose what you did wrong and address it, and the next time maybe the answer will be yes.
Just keep these five tips in mind, and your project will be on its way to a green light:
Ryan Haveson has more than 15 years of experience leading engineering teams and delivering software and services for some of the world’s most recognized brands, including Xbox and Windows. He was a group manager in the Windows Experience team for Windows 8. He and his team designed and delivered end-user and developer-facing features, including the live tile notifications platform and the new Task Manager. He’s currently leading the engineering systems group at Qualcomm Inc. for the Windows/Windows Phone on Snapdragon division in sunny San Diego. Reach him at firstname.lastname@example.org or at linkedin.com/in/ryanha.