Skip to content

IT Project Portfolio: Solution Prototype 7

July 17, 2008


The solution outline is the culmination of all the previous steps. It is a technical document that will be the main resource for the solution after funding has been approved. Many organizations will get the business units to sign off on this document, but most users do not know what they are signing, so don’t put too much weight on their signatures. Do, however, review the document with them to ensure you have captured the business drivers and guiding principles of the opportunity.

The important thing to remember is that the documents will contain all the relevant technical information for the proposed opportunity. Depending on the scale and scope of the solution, this document can be large and not a pretty read, but by culling this document you can build the requirements for the solution and for any Requests for Proposal (RFPs) that may need to be created as a result of this opportunity getting funded. It will become an invaluable resource for your technical team even if it becomes a shelf-filler for your business units.

Your solution outline may contain some, all, or even more than the following items:

  • Introduction.

  • Business scope.

  • Core businesses and services.

  • Mission statement and guiding principals. Clearly state the guiding principles in the solution outline. This will ensure all players understand the overall guidelines of the solution being proposed.

  • Core business.

  • Programs.

  • Services.

  • Types of individuals and organizations.

  • Client needs.

  • Goals.

  • Business drivers.

  • Architecture overview – introduction.

  • Architecture overview – enterprise view.

  • User groups and delivery channels.

  • Business services.

  • Resources.

  • Architecture overview – components view.

  • Presentation services.

  • Architecture overview – software view.

  • Architecture overview – IT system view.

  • Logical technical architecture.

  • Architecture overview – physical view.

  • Non-functional (operational) requirements – Do not overlook the importance of getting in writing some of the non-functional constraints.

  • IT standards – It is always good to state the baseline for which the solution must adhere to. This will give valuable insight into why certain technical decisions where made long after the opportunity has passed and the designers have moved on.

Stage 7 Deliverables

  • Revised functional requirements.

  • Revised non-functional requirements.

  • Update to logical architecture.

  • Update to physical architecture.

  • Solution costing;

  • Support model and costing.

  • Final report back on solution to business area.

Stage 7 Outcomes

  • Final report on solution outline and high level costs (+/- 10%).

Stage 7 Duration

  • One to two week

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: