How to Justify Application Modernization to your CFO – Episode 2

In our last episode, our hero (you, of course) was preparing to make an ROI-powered business case for Application Modernization to your CFO.  We covered your current resources, your goals, and steps 1-4 in the process.

This episode unveils Step 5 – Conducting a Project Scope.

A Project Scope may also be called a Project Study or a Requirements Analysis.  The name is not of importance; the Input, Activities and Output are.  So let’s go through each of those in some detail.

Input to a Project Scope

Before starting on a Project Scope, we need some basic ingredients:

• A sensible modernization initiative with promising ROI potential
• Significant interest from the business
• At least a small mandate from the executive level

If you haven’t yet achieved these necessary inputs, I encourage you to review steps 1-4.
Project Scope Activities
Project Scope activities vary based on the size and complexity of the potential project, however they usually consist of in-person meetings and focused time to create deliverables.

In-person meetings should be based on an agenda, with all attendees allocating an appropriate amount of time and energy. You don’t need (or even want) all resources to attend the entire agenda, but all the key resources should attend an introduction wherein the business impetus and vision of the initiative are outlined, and the purpose for the Project Scope is made clear to all.

A sample Project Scope meeting agenda might look like …

It is critical that the the majority of the attendees from each group are ‘on board’ and focused on success. If this is not the case, then perhaps action should be taken to ensure the group is working towards common goals.

Best practices of running a meeting also apply to the Project Scope meetings of course. Keep the meeting on track as much as practical, hit all the topics, ensure everyone has a voice, and record everything pertinent. Tip: pre-configure a spreadsheet or word document with space to record key points and action items against each of the agenda topics. This will help you to be organized.  Click for a sample note-taker template.

Project Scope Output

With the meetings concluded, it’s time to isolate yourself in the creation of the Project Scope deliverables. If you’re like me, quiet focused time is needed in order to wrap your brain around all the new material you uncovered and to use your creative skills. Typical Project Scope deliverables include:

• Business Vision Statement
• Non-functional requirements
• Functional Requirements
• Design, which depending on the project may include:
  • A data model
  • A breakdown of functionality into modules
  • Process Flow /Data Flow/ Use Case diagrams
  • Security and User Access considerations
  • User Interface, including layout, navigation, content areas and graphical themes
  • Complex calculations and other UI-free routines
  • System Integration strategy for each partner system
  • Reports, Generated Documents, Dashboards, etc.
• Report of all Project Risks and how they will be addressed
• Prototypes, in order to address identified risk areas and draw out early feedback and support
• Project Plan, perhaps in MS Project format, with all known tasks, resources, dependencies, effort
• Project Management Methodology, including meetings, archives, time reporting, quality, etc.

Before you get started, estimate the effort and resources needed to produce each Project Scope deliverable. Depending on the size and complexity of the project, you may need to pull in specific skills and delegate some of the work.

Now let’s briefly run through each deliverable …

The Business Vision Statement is the start of the story. It should outline the state of the organization/department today, what it does and perhaps how it does it. It must also explain how market conditions are changing and what challenges and opportunities this presents to the organization and its competitors. Finally, it should describe the desirable future-state without worrying about the voyage.

Non-functional Requirements are those that restrict the design or operations of the system, but don’t describe its actual behavior. Examples are Compliance Standards that must be respected, Interoperability with other systems, Response Times, Deployment, Backup and Recovery, Configurability and Documentation. These may restrict creativity in the design, which sounds bad, but are necessary to ensure that the system deliverable is actually something that can be successfully implemented and maintained.

Most Functional Requirements are best described in Use Cases. The concept of Use Cases was created by Ivar Jacobson and popularized by proponents of the Universal Modeling Language (UML). Each Use Case describes one interaction with the system. It consists of a goal, pre-conditions, post conditions, business rules, actors that interact with the system, stakeholders which care about the results, a flow schematic with banded roles, and a textual description of one or more courses of events. However, some Functional Requirements, such as complex routines, have no actor, little or no flow, and are better described in good old pseudo-code.

The elements of Design itself are many, and will vary greatly based on the type of system being envisioned. In the case of a Modernization project, the design will usually analyze the existing system and categorize its elements into those that will be retained, modified or replaced. The design also needs to outline the new parts of the system and  summarize the process for any repetitive transformation that will occur.

I’ll use an example to illustrate. Let’s assume that we have a text-based legacy system that we want to modernize. It has been around for a long time and has successfully run the traditional business. However it is a closed system, while the market is calling for Internet-based collaboration with customers and partners. We might provide a simple breakdown of the design elements as follows:

In this example, the company’s financial modules are performing well and do not need to change to satisfy the business vision; they are retained as is. The inventory allocation and product pricing routines need minor modification to ensure that they are externally callable. The Customer Service user interface is functional, but needs to be made graphical to boost user productivity and reduce training time. The rest is completely new functionality – still, it will make use of the existing database.

With this high-level categorization complete, we can now delve into each piece of functionality and determine which will be purchased and which will be built. A sensible third choice is emerging today: pre-built system modules whose source code can be customized and maintained in-house. These code-starters may be open source modules, or they may offerings supported by specialized software & consulting organizations. If the decision is to purchase a software product, the design must outline how it will be integrated and modified. If a home-grown system is to be built, the design effort will be greater.

Moving on from the Design deliverable of the Project Scope, I find the most neglected are the last four Project Scope deliverables: Risk Assessment, Prototypes, Project Plan and Project Methodology.  That’s too much to cover here, but I’ll be sure to detail these in later posts.

So that covers Step 5 in our hero’s quest to Justify Application Modernization to a CFO – Conducting a Project Scope.  Hopefully you’ll be able to apply some of this to your next project opportunity at your organization.  If you need some guidance, feel free to contact me.

What’s next?

In the next episodes, our hero will perform calculations to predict a project’s Return on Investment and build a presentation to educate and convince the CFO … toward the ultimate prize of being awarded a mandate to actually deliver the project and gain the admiration of the masses!

Read Episode 1

Read Episode 3