← Part 2 What gets measured gets managed.
Strategy & Planning Deliverables
Owner or sponsor input should be first here and it should be the baseline for the value proposition that will evolve the more the system needs take shape. Owner input defines the mission and the mandate whereas the vision is to be defined by the project leader and team.
As long as anyone has questions about the purpose and objectives of the competitive intelligence software and it’s value for the business, the strategy is either not defined or not communicated well enough.
Planning should also start early-on with a helicopter view and become more detailed over time. A basic folder structure on a SharePoint and month-by-month Gantt chart that shows the project phases as outlined in this article will do initially.
Some principles can also be defined at this point: communication plan, user-on-boarding through train-the-trainer or super user structures for example. These might be driven by the company’s communication culture and experience with comparable projects and solutions.
Seems obvious but this deliverable needs a very strong foundation both in people expressing the mandate and in documenting inquiry and objectives.
For a long lasting and deeply impacting project like selecting and implementing a competitive intelligence system the mandate can also serve as a 30 seconds elevator pitch and value proposition for anyone who needs to be educated about the need and value of the project.
The mandate lends credibility and a sense of importance (in some cases urgency) to the project owner. It is the launch pad for the development of the project strategy.
Any large project requires buy-in and any investor wants pay-back. A CEO or board of directors who invest into a competitive intelligence software and modernized strategic insights processes (both should be systematically aligned) need to clearly communicate why they invest.
Maybe because they witnessed a competitor beat them to market or they took ill advised decisions because of competitive blindspots or because they are afraid to suffer disruption and want to be better prepared.
Be it what may: the project leader needs to formulate these wants into a vision that acts like a very motivating goal for everyone involved.
If a vision for such an impacting project (well, the project is a lot less impacting than the ever changing way how to perceive and how to play the market once it is up and running) is not understood and enthusiastically followed, then it either needs some more word smithing and/or is not well enough communicated or it is not a vision worth following in the eye of the recipients.
A co-creation session together with experienced strategists, communication staff and several stakeholder who should inherit that vision should result in a vision that is both engaging and goal oriented.
You can read about vision, mission and values in a marketing environment in this article.
Despite the obvious variables for size of project and resources available the team sheet should include at least:
- Sponsor (preferably a managerial end user, CxO)
- Owner, project leader
- IT project partner
- Legal advisor
- Team members representing key stakeholder departments (one of which would be co-project lead during a potential pilot phase if it focuses on one department as an early adopter)
- External partner, consultant if given substantial project responsibilities
Project Initiation Document (PID)
This is the framework that sketches the initial project setup and it provides a foundation for the project. It specifies why the project is important, what will be delivered, when it will be delivered and how.
The following main chapters are crucial for a typical competitive intelligence system implementation project:
- Purpose of the Project Initiation Document
- Strategy: Vision, Objectives
- Critical Success Factors
- Project Plan
- Project Risks & Known Issues
- Project Constraints, Assumptions and Interfaces with other Projects
- Project Organization
- The System
The project charter or project plan is the central nervous system of the project. It manages and controls all project activities and resources along the major project phases as described above.
Oftentimes a Gantt chart style is used. Column headers indicate what gets controlled here:
- Project Phases & Objectives
- Activities & Tasks
- Start Date
- End Date
- Work Days
- Status (traffic light color coding with commentary can be powerful project controls, especially when risk is to be mitigated or delays to be addressed)
- Calendar Grid
It is also crucial to show the actors’ availability and contact information in the same view for transparent resource allocation and timeline planning.
In order to establish a focused structure to develop the systems specifications, top level requirements should be defined in the following areas:
A) User Requirements
Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability:
- Operational distribution or deployment: Where will the system be used?
- Mission profile or scenario: How will the system accomplish its mission objective?
- Performance and related parameters: What are the critical system parameters to accomplish the mission?
- Utilization environments: How are the various system components to be used?
- Effectiveness requirements: How effective or efficient must the system be in performing its mission?
- Operational life cycle: How long will the system be in use by the user?
- Environment: What environments will the system be expected to operate in an effective manner?
B) Architectural Requirements
Architectural requirements explain what has to be done by identifying the necessary systems architecture of a system.
C) Structural Requirements
Structural requirements explain what has to be done by identifying the necessary structure of a system.
D) Behavioral Requirements
Behavioral requirements explain what has to be done by identifying the necessary behavior of a system.
E) Functional Requirements
Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the top level functions for functional analysis.
F) Non-functional Requirements
Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.
G) Core Functionality and Ancillary Functionality Requirements
Murali Krishna Chemuturi, the popular Indian software development expert, defined requirements into Core Functionality and Ancillary Functionality requirements. Core Functionality requirements are those without fulfilling which the product cannot be useful at all.
Ancillary Functionality requirements are those that are supportive to Core Functionality. The product can continue to work even if some or all of the Ancillary Functionality requirements are fulfilled but with some side effects. Security, safety, user friendliness and so on are examples of Ancillary Functionality requirements.
H) Performance Requirements
The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.
I) Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.
Project KPI dashboard
This can be simple in design but really crucial for the much needed management support for the project.
The project KPI dashboard should be a one-pager, visualizing the entirety of the project plan, indicating key objectives and timelines and plotting the status quo into it. Flags should qualify and alert.
This is the project leader’s visual equivalent to the 30 second elevator speech. With an important difference: once shown or sent to anyone it moves out of control. So, keep it simple, easy to read and without follow-up questions being triggered.
An easily accessible and universally usable structure should be established that works cross-platform, is safe and includes external partners.
It is recommended to use an environment that is most commonly used by the key players of the project and can be serviced 24/7 with internal IT resources to limit dependencies.
Regardless if SharePoint, Lotus Notes, a network drive or web based collaboration portal is used, the following containers and work areas might be a good starting point:
Agreements, access codes, service and support guidelines, policy documents, schedules.
Collections of research material, related projects, historic experience and reports, initiation documentation, stakeholder related work areas where meeting documents and their collections can be gathered and archived.
Everything that describes the various decisions and options, initiatives and sub projects. As a baseline the owner input can be stored here and everything that responds to it like kick-off sequence, vision, mission and strategy map.
All tools and documents that make the project run and measure its progress like project plans and worksheets for consultants. This is very likely the most active area and used by scores of contributors so it needs to be simple, robust and agreed upon by all users.
Throughout the project there are several analysis that produce baseline documents, descriptions, evaluation tools, tables and lists.
Classic collections in this area are solution provider profiles, screen shots, recorded demo videos, testimonials, primer files and summaries, comparison and benchmark spreadsheets, price and cost comparisons, score sheets and presentations about all of the above.
Specifications, content structures, taxonomy and user interface designs are developed, stored and shared here. Pretty much everything to fulfill the user needs and won’t need extra development.
When there are functions and content that need to be developed, this special area should give space for system developers and work teams that develop use cases for extra needs not covered by the solution provider’s standard offer.
Q&A catalogues, glossaries and user guideline documentation can be developed here over time. Legal policies and a robust code of ethics are further examples and show how cross-departmental development needs its extra space and time.
Rolling out a global system used by hundreds or thousands of employees can be incredibly complex and requires professional structure and management.
It is strongly advised to launch large go-live sequences with a pilot and health check first. This also provides the opportunity for improvements before the global roll-out. There might even be a separate pilot team with its own collaboration platform and reporting.
Long term preparation and complete, careful communication to reach every stakeholder and don’t leave anyone wondering or incapable to understand their role and options are key and should be reviewed and improved by all active project stakeholders.
Throughout the project there are several reporting needs and formats. It is advisable to keep them all in one area as some are interdependent and project leaders want to trace all developments in an easy way.
KPI dashboards, data feeds and slide decks for decision making should be handled here.
Part 4 → Specifications & Design Deliverables →→