Description
Many business models today are a blend of business processes and project management. A project manager with a strong combination of business acumen, technical competence, and clear concise communication often directs successful eBusiness and integrated supply chain management initiatives. This combination of process and project implies a series of repeatable steps that are similar across individual projects, which in-turn drives an interesting ability to achieve rapid implementation and lower cost by reusing artifacts across the enterprise.
The challenge involves making sure the proper information is gathered and shared at the appropriate time across multiple organizations – both inside and outside your company. This matrix is often comprised of individuals in an ‘operations’ environment as well as in a product or an IT development group. People cannot spend time wading through reams of documentation to find the information that is critical to their tasks on the Work Breakdown Structure (WBS). There is also a critical need to line up support organizations and equip teams with critical information and adequate lead-time to be prepared according to the schedule.
The use of Project Maps is a successful technique to manage this complex matrix of people, information, time, and correspondence for Enterprise Application Integration. Project maps allow the creation of an enterprise wide library of documentation and templates to maximize reusability yet insure the uniqueness required by each project.
What is a Project Map?
My definition of a project map is as follows:
“A project map is where various templates are defined in-lock-step with a business service being provided.
A project map allows the definition and workflow of various project templates to be organized into a repeatable process.”
The up front project plan and contact list and other templates are similar – so are reusable, but the values vary. While many items to be examined in risk mitigation analysis may be repeatable, but based on the service, the actual templates and documentation may differ. In a nutshell – a map lists what documentation is required for the type of project being managed.
I like the term map for many reasons. There are many different definitions for a map, one definition states that a map is an action for which a person or thing is specially fitted. Another definition implies the clarity – a representation of whole or part of an area. A map is a tool to help define a direction. A map is not a device to tell where you are or even where you are headed. A map provides the locations of various landmarks and their relationship to each other. Combined with directions – it can tell you WHERE you are going and HOW to get there. A map is a tool that must be used with other tools in order to be useful. The map's legend will demonstrate which way is north, but the individual will need a compass to know which direction they are facing when trying to use the map. Additionally, the map might outline where there are traffic lights on the path, but it doesn't tell you what lights are red or green when you get to them. The person leading the team on the journey (or shall we say the person managing the project) needs to be able to process current information against the map to have the team prepared for what is ahead and make sure the final destination is met.
The map analogy illustrates the concept of defining various pieces of correspondence to be delivered or received at critical points along the project. Enterprise Application Integration projects usually involve a wide breadth of technical capability of which only a small subset is being implemented for a particular project. For example, a suite of applications may involve billing, payroll, ordering, and inventory, but a company is only implementing the payroll module. A project map will direct what templates, forms, and technical documentation need to be used for managing this project. Using the previous example, it would be a waste of time to perform tasks exclusive to the inventory capability of the application suite if the customer is only using payroll. The map would define the steps for payroll within the enterprise of all components in the suite.
Enterprise Application Integration (EAI)
Enterprise Application Integration refers to the process of combining multiple organization applications through an extensible electronic interfaced. This involves capabilities such as using eXtensible Markup Language (XML), web services, or supply chain management applications. An EAI project creates a seamless interface between two organizations where only ‘exceptions’ are handled manually. Each company has a large resource investment and many critical tasks within the project and project management must be coordinated between the organizations.
Enterprise Application Integration does not involve new development as much as it involves development to extend an application to utilize another well-defined set of rules and functionality. An EAI project is a blending of technology, business processes, cultures, and cross company responsibilities. This includes a library of project artifacts and strict process for baselining scope, work breakdown structures and test plans, as well as stringent change control.
A project map in EAI will define the components for an organization so they can focus on what they need, rather than filter out all information from all sources. In an EAI project, the project manager is responsible for defining what information is shared with whom and how they relate to one another. It has been common practice for years to apply filters to project files so an organization can only focus on their relevant tasks. EAI projects take that across a matrix in multiple companies and organizations. The big picture is scaled down to defined operational type tasks.
Important Note: I still think its imperative that the big picture, and how each task fits in the big picture, are made available to all members of the team. The distinction on the project map is the individual has their individual tasks and details filtered for them from the big picture – rather than dig through all the details to find what is relevant to them.
Repeatable Project
Another major concept in project mapping is the concept of a repeatable project. At first glance, the term repeatable project may be considered an oxymoron. After all, a project is a unique set of tasks with a defined beginning and a defined end. The concept of repeating, or reusability, is more aligned with an operations or running the business “RTB” model. Yet, in EAI projects the steps may be very similar for multiple implementations. As an EAI supplier, you may be installing payroll applications for multiple customers the steps of preparing the technology may be the same and even involve the same resources. For example: install servers and initialize the database may be the same for every company that uses the application, yet many applications are advertised as ‘customizable’ so the database may have to have special fields added or views created to meet a customer need.
This relationship between customizable per customer and performance of the same tasks for all customers is the basis for project mapping. The level of customization or components that need to be implemented on a project can be captured on one common qualification document. (I hesitate to use the term template or form here because a map may be defined based on the values in the form.) The values on this form will define the map which will in-turn define which correspondence needs to be shared to the project team for meeting the project objectives. In a repeatable project environment, the project scope may actually be defined by values placed on an order form from the sales department and not a sponsored charter from a project champion.
As in any project, the project manager is responsible to make sure all task holders and stakeholders in the project matrix understand the following:
- What is to be done
- Why it needs to be done
- Who is to get it done
- When it is to be done
- Constraints
- Dependencies
- Have all the necessary material to do it
- Intellectual
- Physical
- Can report its progress & issues as it is being done
- Reporting to the team that it has been done
Along with this list, the project manager also needs to make sure it is communicated through current, consistent, clear, concise, and comprehensible content.
A Simple Example
Now that a framework has been developed that defines a project map and a repeatable project, I am going to take a huge risk and try to create a simple example/analogy to further define a project map. This example is intended to demonstrate the flexibility a map offers within a small domain of similar/repeatable projects.
The basis for this map is projects that involve plumbing. An organization provides a service where they install plumbing fixtures. In this example, the process involves either a piece of plumbing in a kitchen or a bathroom. There are similarities: each involves fresh water be brought to the room, each requires waste water be flowed away from the room. There are several differences: size of the basins, electrical needs, way water temperature is controlled, etc. A company that would be performing these projects may very well have a common form at the beginning that is used to capture the customer requirements, invoice the customer, provide a statement of work, and outline the scope of the project. It is possible in this simple scenario that the document (template) may include a schedule. Exhibit 1 demonstrates the simple components that make up the map. (This analogy can be broken down further into saying it outlines the ‘landmarks’ on a map). It displays all the possible steps and correspondence in the domain of this repeatable project.
The domain defined in Exhibit 1 implies the first step in the process is to define the user requirements. In our example, this purchase order template is filled out. There is a choice of a plumbing job for either the kitchen or the bathroom. Drilling further down there are different components required based on if it is a combination of plumbing and electricity or if there is no electricity needed. Each map comes together at the purchase of the components. This demonstrates that multiple maps can share the same process (and consequently the same forms and documents). Finally, after purchasing the components, there are different steps for installing a component KE - Kitchen Electric, KNE – Kitchen No Electric, BE - Bathroom electric, BNE - Bathroom No Electric.
Exhibit 2 shows a populated map for the installation of a garbage disposable. The requirements are defined for both projects – based on the value in that template, the artifacts, documentation, and tasks for Kitchen are then executed. Further, within the Kitchen domain, the steps required for a project that involves electricity. Again, this maps to the common process that involves purchasing the components. Finally, there are instructions specific to installing a kitchen component with electricity.
Exhibit 3 shows a template map for the garbage disposal project in a text/table layout. The purpose of this tale is to demonstrate that certain components can be extracted from a library and shared to key task holders on the project without sharing the whole library. For this project, there was no need to share information for installing a whirlpool in a bathroom, so that component was filtered out and the information required for this project was mapped to the stakeholder. The imaginary table also highlights that each template, or artifact in the domain, can be at various version levels.
Artifacts
I like to use the term artifact to define various pieces of documentation related to a project. An artifact by definition is: “Something created by humans usually for a practical purpose that has enduring value”. Thus, I think it fits quite nicely into defining all the correspondence required for project maps. The artifact is the result and often times is base lined or is somehow managed through document management or change control. A blank template is not an artifact, once the template has been populated and ‘base lined’ it then becomes an artifact. However, a template can be an intricate part of the project map. The map will drive to a template that needs to be populated to become an artifact. The rest of this section defines components in the map domain and how they relate to becoming artifacts.
Templates and Forms
A template or form is a document with placeholders for certain pieces of information critical to defining the project. A template has placeholders that can be added, deleted or moved around. It is a guideline for how to capture and report information. A form is standard and has concrete defined field names that cannot be deleted or moved. A defined input screen into a program management system is a form.
Templates and forms are critical in defining all the artifacts in the project map. As previously mentioned, for repeatable projects a populated template or form may drive the project charter and define the scope of the project. Although the project map domain may point to a template for the project plan and upfront documentation - it should in no way lessen the amount of effort required for those steps.
Some project map environments have tasks in the work breakdown structures defined via a template. There is not enough room in this document to detail all the issues regarding managing templates and WBS tasks but for the purpose of this document, a project map can define tasks in the WBS. A WBS template may utilize field filters to map the task within the project domain.
Note: There can also be templates and forms specific to controlling the project. A status report form can be defined in the project map for consistent reporting of multiple projects across the program. Of course, many of the control reports could also be formatted reports from the Program Management System being used by the organization.
Storyboard
A storyboard is taking a real life example and simulating its progress through the new EAI environment. A storyboard should be technology independent and focus on the business handling of the various components. A storyboard can be the foundation for both technical requirements and identification of artifacts in the project map.
Requirements
Requirements define the technical details of the projects. Requirements need to be singular and traceable and drive many other artifacts in the project map. For example: test plans should be able to validate each requirement was achieved.
With EAI Repeatable Projects, the requirements may also include a checklist of capabilities in the suite if functions available. If we revisit the payroll example earlier – there may be many requirements, that need to be specified within payroll capability, to make sure it meets the user need.
Documentation
Documentation is a generic term to define the technical reference that defines how the technical components function in the EAI applications. Documentation is static and does not change based on the functions being implemented in the EAI project. The complete documentation library may contains scores of different artifacts and the project map will define which pieces of documentation need to be provided to key task holders in the project. There may also be defined steps in the WBS that define reviewing the documentation.
The 15 plus megabyte schema dilemma.
There is a company that is currently rolling out a completely integrated XML feature that allows customers to order, check status, and do invoicing for all products and services this company offers. The IT department has made an extensive normalized XML schema that defines every possible situation necessary for implementing EAI. Unfortunately, the documentation that is created, that defines the schemas, all related rules, and generic examples, ends up being a 15-megabyte several hundred-page file. It is overwhelming. Huge documentation files are a significant risk factor in an EAI project. The use of a project map will be able to help the project team focus on the sections of the 15-megabyte document specific to the functions being implemented. The team may actually want to give the customer a condensed document copy with the sections they need and the big 15-megabyte file as a backup.
Tracking Artifacts
A project map is not complete unless the components are defined, completed, and tracked that all key stakeholders are satisfied. If we go back to the definition of a map – it was presented that a map is just an action that is specifically fitted to a need. The map cannot tell you if you are headed in the right direction or what traffic lights will be red or green. The normal controlling and execution of the project requires that. The project manager needs to utilize the map in their normal routine of evaluating and re-planning the project.
The project map should have the major milestones defined with entrance and exit criteria for each. The WBS needs to be in line with the map and the map needs to be in lockstep with business processes. The operations groups in the matrix are not in a development world and probably have a completely different view of variance than a development.
Building Your Own Maps
My experience with project maps involves implementing EAI applications for the telecommunication industry. We have developed 12 different project maps over the course of 18 months and are constantly revisiting the maps. We started small with two high level maps and a couple of templates. We now are struggling with managing template explosion and making sure the maps are useful and making sure we're in lockstep with business processes.
When defining project maps in your organization – use some of the same principles that you might use to define the project scope and requirements. Storyboard your process and define the large milestones (or landmarks if you want to use a map term) and what are the components required to enter and exit each milestone. Define the templates and forms for each of these landmarks and make sure the critical information is captured and then stored in an artifact. Build upon the initial map to define subsequent maps. This may drive requirements to the technical support team to break down the documentation into smaller components.
Not to be omitted, another factor of defining the map is to establish the audience for each artifact. For example, a storyboard may be shared with business process owners, while the technical schemas may go to programmers and not the business process owners. Many artifacts are defined based on the culture of the organization that may have a different audience. For example, I am a firm believer in creating a 7-slide deck presentation that is an executive overview for a project. I find it quite useful to summarize the project and give stakeholders something they can share with their management structure. This may be a component on a map for all project managers in the program, or may be an artifact used by the discretion of the project manager.
Conclusion
Project maps are a way to streamline the correspondence in an EAI project to allow the key task holders and stakeholders to concentrate on their specific tasks without having to filter through large volumes of information. A project map will define which templates and forms should be used to capture information to provision a customer in an EAI application. Project maps are essential for reusing artifacts and documentation repeatable process projects.