Skip to content

IT Project Portfolio: Verify Business Demands 2

July 12, 2008


This area focuses on further refining the business input, its operating procedures, and its opportunity assumptions. The existing and proposed business models must be defined for any proposed solution since the proposed solution must be able to support the activities of the business unit.

Traditionally, feasibility studies can cover up to and including this stage. All the work done here is to further define and clearly state what currently occurs and how the business unit would like proceed. By knowing these guidelines, the technical team can always check to ensure the solution does not deviate from stated objectives.

Core Business

The core business definition is used to validate the overall objectives of any opportunity. If the opportunity does not complement or satisfy the core business, then it may need to be reconsidered. The focus of these core statements is critical to maintaining the integrity of the solution since, should that focus change over time, the solution will be affected. This is recognition that the solution must be designed to be as dynamic and flexible as necessary to manage changes over time.

It never ceases to amaze the number of groups that cannot clearly articulate the business they are in. Many a time I have heard from the accounting department in a manufacturing company that their departmental business is making widgets. Yes, they are critical to the success of the making of widgets; however, what business is the accounting department in? When I hear phrases like, “we are in the business of collecting, collating and deciphering the business transactions for the organization,” I am confident the process is going to have a successful outcome. Success is not always measured by the opportunity being realized; many times it is that the sponsors have accepted the opportunity, worked the process, and that they trust the IT department is giving unbiased support for all elements of the organization.


Programs are the major methods for delivery of the core business functions, and can either be formal or informal. Continuing the accounting example above, some programs offered by the accounting department could be Accounts Payables and Accounts Receivables.

Programs are how the business unit is broken down to functionally manage their services. Not having an articulation of the business and their programs will make any solution definition incomplete. Every step of the process must be able answer the questions: is it supporting the business and, by definition, is it helping in defined program areas? This is a good acid test to ensure the opportunity is being supported and sponsored by the correct group. Many an opportunity, when it gets into the hands of the IT department, turns into an IT project. This is because the opportunity team is not ensuring the core business and program areas are driving the project. Business solutions should not be lead by IT teams. Having said this, it is imperative that IT representation is present in order to ensure all elements of the organization are covered by any technical solution proposed.


Services deliver value to members of a target group. Typically, this is where the program areas interact with other areas of the organization or customer base. Again, following the above example, the Accounts Payable program area may have a service provision for printing Vendor checks.

Typically, an opportunity is addressing key service areas. This exercise should clearly identify the services the proposed solution is addressing. The service areas, at times, may need to add, change, or delete service components. For example, automating approvals and check printing may have a direct impact on an existing check-printing service. This services definition is especially important in any outsourcing engagement opportunity. By not clearly articulating the as-is services, the new services may overlook key areas that cannot be performed by the new service, and adoption of a final solution will naturally fail under that oversight.

Client Profiles and Scenarios

Specific client areas that will benefit from the opportunity are defined. By breaking down the clients into groups, the business unit will be able to define common wants and needs. This client profiling is used to build scenarios.

Scenarios are structured walkthroughs of the proposed solution. Once the profiles and scenario are defined, a series of business unit engagements can be used to build the use cases. Use cases are nothing more than documents in clear business language to define the specific steps of any given user scenario. If you spend the time in the scenario definition, then the facilitation of the use cases is infinitely easier. (Do not allow the technical team to hijack these meetings. The goal of the scenario workshops is not to start coding, but to garner the spirit of the opportunity and its touch-points with the clients and, ultimately, the solution.

The use cases should focus on the actors, events, and triggers that happen. In simple terms, the actors are the internal or external users of the system; the events are the functions to be performed; and the trigger is what caused the function to commence. Do not get carried away with defining all the business rules, but focus instead on the interaction between actors, events, and business units.

Environmental Scan

Before you engage too far it is always best to get an assessment of what solutions already exist, so best practices and best-of-breed solutions should be researched. The usual magazines, trade papers, and technology Web sites are excellent resources. Today, it is becoming easier to find off-the-shelf products for many solutions.

Colleagues are also an excellent place to source ideas. Learn from the ones who have walked the path first. Look for lessons learned and comparative analysis. Don’t forget to weigh your needs against the features and do not get lured into features you don’t need and possibly will never use.

The key is to look at things from many perspectives, and weigh existing solutions against the maturity model of your organization. You may be able to find the best-of-breed solution from a given product domain, but is your organization able to understand it and use it? Beginning with a smaller solution to get the organization prepared for a more formal discipline is a good approach. Many of the steps described here are not wasted when putting in a smaller, less function-rich solution. Many purists may disagree with this, but too many large projects cannot get out of the starting gate because the organization cannot get its head wrapped around the larger, more complex system. But when this “start small” approach is taken, it is imperative that the organization realizes those solutions are transitional solutions and elements of the final solution. Not all of this interim solution may be used in the final solution, but nor is it a “throw-away” diversion.

Stage 2 Deliverables

  • Definitions for core business, programs, and services.

  • Validate the opportunity goals.

  • Further define the business drivers.

  • Define the governance model.

  • Environmental scan.

  • Input into the solution outline.

Stage 2 Outcomes

  • Use cases profile definitions and for more traditional approaches the feasibility study.

Stage 2 Duration

  • One to two weeks

One Comment leave one →


  1. Bookmarks about Scenarios

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: