Emerging Tech

Five questions to ask before approving a project

By asking a few questions at the start of a project, organizations can improve their successful project completion rate and enjoy the fruits of their success instead of performing post mortems on failed initiatives.

It's common knowledge that technology projects often suffer from spectacular failure, whether that failure means that a project simply couldn't come to fruition or it fails to meet stated goals.  Believe it or not, though, not all IT projects need to fail.  By asking a few questions at the start of a project, organizations can improve their successful project completion rate and enjoy the fruits of their success instead of performing post mortems on failed initiatives.

1. How does the project fit into the current portfolio?

This is, perhaps, the most important question that should be asked at project inception and includes a number of component questions that make up the whole.  Project portfolio management is not always done well.  When poorly handled, this leads to organizations oversubscribing their finite IT resources, which in turn leads to failure across multiple projects.

In addition to ensuring that IT resources aren't overburdened, this question will provide answers to the following portfolio based information needs:

  • What strategic goals does the project meet? Projects should be aligned with business goals. By outlining these goals ahead of time, projects can be better prioritized.
  • Where does this project fall with regard to other projects? By ordering projects by priority, all members of the organization can see what will be worked on and when.

2. Do I really have the resources necessary for successful project completion?

Do you have a $20 appetite but only have $5 in your wallet?  That's also the case with many organizations that undertake complex IT projects.  Further, many projects underestimate both the people and the financial resources that will be necessary for successful completion.  As a part of answering this question, project leaders also need to gain a commitment from project participants that constant fires and shifting priorities will not sway them from meeting stated project goals.  This is the biggest challenge faced by project teams that have other organizational responsibilities.  There needs to be commitment at the executive level that the project will get the promised attention or agreement that a project can slip if other priorities come up.

Further, make sure to include all costs in project estimates.  Now, do you have enough money to get it done?  Don't try to do it for less than it will require.  While superhuman efforts might make it work, the end result will probably not be pretty.

3. Is the timeline that I've put forth truly achievable?

This question is related to the previous one, but it's really important.  Once you've created a timeline for the project, share it with some people before you commit to it.  Further, before you commit, add 25% to the timeline if you can.  No one will mind if you end up coming in a bit early because of overestimated time frames, but they will certainly mind if you miss milestones or an implementation deadline due to poorly conceived plans.

I want to reiterate here that it's critical that project teams be given the time necessary to focus on the project.  If a project manager sees that some members are continually being pulled, the entire project is in jeopardy.  This should be documented in regular project updates that are shared with stakeholders and the executive team.

4. What is the fallback plan in case of imminent failure or other issues?

No matter the planning, it's possible that a project will not come off as expected.  If this happens, what's your fall back?  Do you return to an original system?  Do you move forward with partial functionality?  Do you revamp the project schedule?

It's better to have an idea of a direction when things are going well than when you're under the gun.

5. Who are the stakeholders that need to be involved in the project?

Not every member of the company needs to be involved in every project, but you need to make sure that the right people are involved.  For every project, clearly outline every stakeholder and project participant and indicate their part in the process.  Perhaps the sales VP is the primary stakeholder in the project; this is a person that should receive regular complete project updates.  Maybe the accountant plays a small role late in the project.  This person should receive project status updates but may not need to attend every single project meeting.

Importantly, make sure that the right people remain highly engaged throughout the life of the project so that expectations remain constantly managed and so that you can draw on the business expertise that you will need to see projects through to successful completion.


From the high level project prioritization to handling hands-on items at the tactical level, there are some questions that project managers should ask before embarking on a new initiative.


Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...


...in 20 years of consulting and project and program management is this question - Have we properly defined the problem space? It may come before Does this fit into our portfolio. The reason I raise this is that I have shut down a significant amount of project initiatives that had the wrong problem by the tail, thinking it is a technology problem instead of policy or culture. This means the business case cannot be accurate. I am assuming we are prepareing a business case to answer the questions in this article, plus the feasibility questions regarding business process, support, maturity, culture, economic and technical feasibility. Do we have evidence that this is even a problem?


Excellent list, especially when the additional comments are added. However, it seems to be very heavy on the costs side. The benefits side is also important. So four questions ... 1. Are the benefits real? Too often we approve projects based on a dream of what the benefits might be. 2. Do we have a plan in place to monitor the benefits? 3. Have we included the effect of change in our benefits and costs? Implementing change often increases costs and decreases the actual benefits. 4. Is there a positive ROI, an overwhelming requirement or is this a strategic (sub) project? In real life, we sometimes don't have a choice. And sometimes the ROI applies to a complete strategy implementation rather than one project in the group (in which case, you definitely need to monitor overall progress and have a plan for changing horses in mid-stream). But otherwise, there better be a real ROI to justify the spend. Glen Ford,PMP http://www.vproz.ca


Just to underscore the point on including all costs, far too often in IT projects the costs to complete the project are fairly well covered but the costs to operate the new system or service are overlooked. Factors such as additional staffing or other support that are needed for the organization to fully realize the promised benefits and truly achieve the strategic objectives often meet with the cost-containment arm of the organization after the project is "completed". In my view this is often the point at which the failure really occurs. Organizations need to take these factors into account up front and undertake the full financial analysis before they approve a project to ensure that they can afford to go the distance. They are too many completed projects that only deliver around 50% of promised benefit because of a failure to plan properly for the operational financial impact.


If you have not lined up a Sponsor or Champion (or several champions) that have the juice in your organization to approve more money, time, personnel, and other critical resources to a project, or to clear logjams as they occur, you need to do that before approving any project. Make sure this person kicks off your project with a memo/email/meeting or whatever is appropriate for your business. Identifying all of the stakeholders is exceptionally important, but having a champion that can carry the project through the inevitable rough patch is critical.


I would add a sixth one? Are answers to the five questions above driven by fear or an honest assessment.

Scott Lowe
Scott Lowe

Glen, Excellent points. I'm hoping to do a follow up ("5 more things...") at some point and will definitely include these. Scott

Editor's Picks