I.T. Discussion Community!
-Collapse +Expand
Proj Man
Search Proj Man Group:

-Collapse +Expand Proj Man Store

Prestwood eMagazine

August Edition
Subscribe now! It's Free!
Enter your email:

   ► KBRole-Based T...PSDP & ProcessPSDP Project...   Print This     
  From the March 2016 Issue of Prestwood eMag
Proj Man PSDP Project Management:
Project Management - The Feasibility Phase
Posted 14 years ago on 3/2/2006 and updated 10/22/2007
Take Away: An overview of the PSDP feasibility phase.


A Breath from the Hurricane

This article is one of many articles that focus on management of software projects, and lessons learned from real-life software project experiences. Most of these lessons and tips come from Prestwood Software's long history in the software industry, but I will be including lessons learned from other software development organizations as well.

For each article, I will choose one tip or topic to explore, and I will describe how we at Prestwood make use of these prudent practices to better manage our software projects.  This feature isn't designed to be a classroom for Prestwood Software Development Process (PSDP), but I will point out if and where the topic fits into the PSDP methodology.

For this month, I want to discuss project feasibility:

The Feasibility Phase

"The primary goal of the Feasibility Phase is to determine whether the project can and should be done. Key questions answered include:

  • Can the project be accomplished given the parameters explored thus far?

  • Is our consulting firm a good match for the project?

PSDP Lessons Learned.

How often does a software development organization take on a new project, only to discover that the developers can't keep the promises that were made to the customer?  The answer is, too often.

One element missing from the quote above is who should be involved in the feasibility phase.  The answer is, everyone who will be a part of the project.  Managers should always have developers, quality assurance, and systems integration personnel review the project proposal before the work begins.  Everyone's insight and contributions are valuable!

Let's take the first key question: "Can the project be accomplished given the parameters explored thus far?"  It's easy, and quite common, when presented with a new project for the first time to just look at what the customer is asking you to build, and say, "Yes, we can do that!"  But only because you haven't asked the customer enough questions yet.  Then, as you begin gathering the requirements for the project, you find that the customer's wishes far exceed the scope of what you initially agreed to do.

For example, your customer wishes to add functionality to automate a process they are currently doing manually.  At first glance, you're sure that you can find a third-party tool that is tailored to automating that particular process, only to discover in research later on that no such tool exists, and you will have to design it yourself.  However, you have already agreed to do the project based on the assumption that you could find that third-party solution, and your customer is not willing to pony up to the costs of developing that tool.

Had you (or the customer) done the research before you agreed to do the project, you would have been able to present the true cost of the development effort to the customer, and given them the option to back out if the project costs were beyond the acceptable limits of their budget.

Hurricane breaths:

  1. Never make assumptions.  Present your understanding of the project in a memo of understanding, or some other format, and have your customer buy off on your assumptions before you agree to do the work.

  2. Ask the right questions, then ask some more.  Always take into account that either you or the customer knows more about the process than the other.  If you find yourself on unfamiliar ground, ask the customer to explain their business processes.  If the customer doesn't understand the technology you're presenting as a solution, give them the "5 cent tour" of the technology and come to an agreement about whether it is a good fit for them or not.

  3. Chart your course before you sail.  Before you can begin, you need to determine if all of the solutions exist, or if new solutions need to be created (and at what cost).  Explain to the customer that this is a part of the process.  Do the research first.  If the project involves new technology (whether it be operating system, communications, interface, or data persistence), the research will save you and your customer from potential grief.
  4. Give the customer room to say "No".  Be honest, and don't back your customer into a corner.  After you show the customer the scope and cost of the project, give them the chance to take a big gulp and tell you they can't go forward with it.  Not every customer has deep pockets.  You might find that they will return with a simpler project, or come back with the original project after they have secured enough funding.  Or in the best case, they might ask you how to trim the project down to a manageable budget, and then proceed with that.

Linked Message Board Threads

 Scott Wehrley & feasibility in PSDP MB Topic (2 replies)


Share a thought or comment...
Write a Comment...
Sign in...

If you are a member, Sign In. Or, you can Create a Free account now.

Anonymous Post (text-only, no HTML):

Enter your name and security key.

Your Name:
Security key = P1124A1
Enter key:
Article Contributed By Scott Wehrly:

Scott Wehrly is currently working on .Net web applications for the gaming industry. Scott is a former employee of Prestwood Software (he was a Development Manager). Scott's specialties include C#, ASP.Net, MSSQL Server 2005, Delphi, SQL databases, C++, C, and Windows programming in general. When time allows, he participates in this online community.

Visit Profile

 KB Article #100351 Counter
Since 4/2/2008

Follow PrestwoodBoards on: 

©1995-2020 PrestwoodBoards  [Security & Privacy]
Professional IT Services: Coding | Websites | Computer Tech