(Project) Design

EDBOK Guide

What is Project Design?

The Design phase of the project is an important phase. It finalizes, at a detailed level, the requirements, specifications, solutions, and approach for the next phase of development. Depending on the type and size of the organization and the methodology used to manage and resource projects, detailed specifications may already have been produced and signed off during the Analysis phase. When this is the case they are received as input along with other related project documentation and reviewed during this phase.

Many companies produce detailed specifications during this phase. This is the reality of their process, resourcing, skillset, and their relationship with their client and/or project sponsor. This phase is written from the perspective of identifying what must be finalized as the output from the Design phase.

If detailed specifications are produced during this phase it may be necessary to circle back to earlier phases of the lifecycle, such as architecture, business analysis and technical analysis, since fleshing out the detailed specifications here may identify a new business and/or technical requirement that impacts the cost, timeline, and resourcing. Skilled project management is essential in identifying these possible impacts and managing them.

Establishing the Project Team

Some organizations assign a Project Manager early in the lifecycle to manage the activities related to moving a project from an idea through costing and pricing, business and technical analysis, solution definition, and architectural review especially for large and complex projects. Others assign a project manager when the project is approved and funded and moves into the Design phase.

It is imperative in this phase that there is an identified and engaged multi-functional team. The team should have representation from each department / business group that is affected by the project. The team should include decision makers and workers; with the decision makers acting as a steering committee. There should be an executive sponsor to ensure that the project is resourced and allowed to proceed without roadblocks.

The following roles should be involved in the Design phase of the project:

• Project Manager
• Project Sponsor
• Business (Systems) Analyst (either full-time to develop detailed business requirements or part-time to provide clarity)
• Data Specialist
• Workflow Specialist
• Technical Leads with expertise in all technical solutions being proposed.
• Architect
• Application Developers
• Technical Services (Hardware, software, communications , connectivity)
• Operations
• QA Analyst
• Customer Stakeholders including Decision Makers
• Procurement

The skills needed by the Project Team to produce System Requirements are dramatically different from those required to write and then translate the business requirements into a technical design. Business requirements define the what; technical and system requirements define the how.

Procurement may need to be involved if the project requires the purchase, installation and training related to new/additional/upgraded hardware and/or software. The installation of hardware or software may comprise the entire project, or mean a prerequisite larger project. Examples might be the installation of a new printer or inserter to handle growth in print volumes or the installation of a new composition system (including resource hiring or training) to deliver a new statement project.

Not all initiatives are large statement engineering projects and they may not be a Project at all in the formal sense of the word. Many organizations deliver far more change requests than they do large scale projects and the Design stage may be fairly brief, identifying the current state accurately and then designing the future state and how it will be achieved.

Other projects in our industry might include adding a new channel, such as messaging or epresentment to an existing solution; de-commissioning an application; upgrading software or hardware; rebranding output to reflect a merger or acquisition; moving from one software or hardware platform to another; or implementing workflow automation.

The nature of the project will drive the exact nature of the approach and documentation in the design phase. This section should be reviewed with that in mind.

It is common for the team size to expand as you progress through this phase to be sure that the range of skills is adequate for the task. There can be an advantage to keeping some of the original team intact while progressing to this phase to retain continuity in the business knowledge and functional expertise from earlier phases.

At this point in the project any training and support needs must be identified, as well as all equipment and communications needs.

Design Steps

The following steps must be completed during this phase to ensure that the planned solution meets the defined requirements at a detailed level:

• All documentation prepared at earlier phases is reviewed to ensure the business rules and requirements and other specifications are defined in sufficient detail. If not, activities are planned and executed to obtain the details in this phase.
• Project documentation is either reviewed or created to ensure clear understanding by all team members of the project purpose, scope, assumptions, timelines, volumes, SLA, deliverables and budget. This documentation should also include the following information, gathered during the previous phases. If it does not, this must be captured and documented in this phase and perhaps be captured as part of the Business Requirements.
  • Overview: This section reflects the intention and describes the project at a high level.
  • Problem Summary:  This section summarizes the basic problem that the customer faces. It includes specifics regarding the customer’s current business scenarios. It also describes the challenges and areas of particular risk. It may also point out areas that are working well so there is minimal disruption to those areas if possible. Those that are working well may also help to pave the way for the eventual solutions.
  • Objectives: This section contains a clear statement concerning the primary goals and objectives of the project. This is a very important section as it will be used to guide the success of the project. Here is where a company should include input from all stakeholders. If possible, the objectives should be measurable. This will help with reporting and benchmarking the solution. Key items to consider are:
    • SLA requirements,
    • Transaction volumes,
    • Transmission frequency,
    • Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for contingency planning, and
    • Security requirements.
• Major Required Features: This section starts out with a high-level, prioritized statement of the features that the project requires. From there, the details of the features are reviewed including information regarding how to implement the features to meet the needs of the customer. The output from the Architecture phase is reviewed to understand how existing and/or new enterprise technologies or solutions can be leveraged for the current design in areas such as composition, data normalization, print and insertion, messaging, archive, e-presentment and other channels. Gaps between installed and required capabilities are identified and a plan put in place to address them.
• The requirement for new hardware or software to support the solution is identified and a project created for procurement, installation, training and support.
• An in depth analysis of all the data structures, forms and business rules. At this stage, similarities, differences, level of complexity and relevance are identified. The goal is to use this information to start to frame the implementation approach and confirm the architecture for the new solution. . The recommendations from this phase will lay out the structure, strengths and functionalities of the software and platform.
• Once all specifications are produced in sufficient detail to either confirm the planned approach or identify gaps, the Project Manager produces detailed task level project plans and a detailed resource plan and reviews all project assumptions and scope to ensure they are still valid.
• Changes are identified and the impact on project timelines, resourcing, cost and budgets are identified. At this point a project cost estimate from previous phases may be refined from a range (e.g. $100 to $150K +/- 20%) to a fixed or more closely defined number for stakeholder approval.

Specifications

The final specifications or outputs from this stage, whether simply reviewed from previous phases, updated or built from scratch, are passed on to the Development phase for the solution to be coded, configured, installed, and/or unit-tested based on the requirements. These requirements are also used as the basis for building plans for testing in the QA and Test phase through traceable testing. They must be written clearly and concisely and the QA and Test Analyst should be consulted about an effective format for writing and archiving of documentation.

If the project is a change request to an existing application, current state documentation should be marked up to demonstrate the future state in appropriate sections to ensure that the exact implications of the change are captured and the documentation remains current for future change management.

Business Requirements should always be reviewed, approved and signed off by the client or sponsor. These are the requirements that will drive development and all the phases that follow and allow Project Managers to manage changes that impact timelines, resources and costs.

Outputs may include the following:

• Data Dictionary: The analyses of all the data structures involved in the creation of the documents. This will include evaluating the detail down to the field level, the field name, its source, field characteristics, type, and content. The work product from this analysis is the critical predecessor for documenting the business rules and creating a comprehensive mapping of the business rules to the data. Based on this analysis, it may be possible to break the implementation into phases based on features like data structures, document types and frequencies and internal priorities.
• Business Requirements: For all pieces of the solution. These may include desired features and operations, screen layouts, business rules process diagrams, pseudo code, file naming conventions and other documentation, Business rules that drive the content of a complex document such as a statement can be very lengthy and detailed and require considerable time and facilitation with business users, who may require time to investigate and make a decision. This area should not be underestimated in planning.
• Document Design Guide: This is often produced by a design or marketing department or a third party design firm that designs the look and feel, information flow and functionality of a new or re-engineered document. The guide will include information such as logos, pictures, font types and other document objects, style usage, colors, page and table break guidelines, wrapping, column formatting and other functionality. It will also include a mockup of the document. If this guide does not exist, this information must be included in the Business Requirements.
• Style Guide: If the company sponsoring the project has a Style Guide that defines the use of their logo, branding, fonts, colors and so on, this should be collected and provided as input to the Development phase.
• Configuration Guides: For existing solutions or products in the current architecture, such as archive or epresentment, configuration guides are produced that define how built- in functionality features are set for this particular project. These are produced in consultation with the business owner and require good knowledge of the solution and good communication skills.
• Functional Requirements: for features such as sorting and bundling, postal sorting, data normalization, special handling, manual processing and so on
• Operations Requirements: for bar codes document integrity, marketing inserts, envelopes, paper, audit and reconciliation, SLA and file splits to accommodate postage tiers, convenience volume splits, work flow etc. More information about these features can be found in other sections of this document, but at the design stage the specific requirements to allow Operations to handle the application in their environment accurately and efficiently must be clearly defined at this stage.
• Technical and Support Requirements: For such items as networking, data receipt, passwords, security protocols, and error reporting.
• Hardware and Software Installation Requirements: For new or upgraded hardware and software projects. This will include items such as floor plans, HVAC and other environmental controls, technology platform specifics, software versions, training, testing, and stress testing.
• Technical Architecture Definition: The purpose of the Technical Architecture is to describe in more detail the high level architectural workflow identified during the Architecture phase and to ensure that the Technical Solution fits into the Enterprise Architecture of the organization and meets the requirements of the project. The technical solution includes information such as terms of the hardware platform, programming development languages, supporting toolsets including third party tools that are to be used in the creation and maintenance of the new solution. It should also document interfaces to databases and other input sources, document objects, archives, preference management and messaging tools, billing, audit and reconciliation and various outputs such as print, archive, epresentment and accessibility formats and also identify various environments for Development, User Acceptance Testing (UAT) and production.