Tokenized Encryption: Details Become Design

 

Once a project such as PCI compliance is approved, the first step is to hold a kickoff meeting. There are numerous reasons for a kickoff meeting: The CIO affirms the project’s importance and defines objectives, team members can acquaint themselves with each other, determine deadlines, identify potential obstacles and possible solutions, and establish requirements. But the most important objective is to establish a high-level project plan. This article explores the steps involved in transforming a high-level project plan into an efficacious, dynamic and comprehensive plan.

What do I mean by elaboration? Tasks vary in scope. There are major tasks, such as installation of a new encryption product (i.e., ICSF and Mega-Cryption). Then there are minor tasks, such as ICSF ordering, customization and testing. Minor tasks may have subtasks such as parameter definition, data set calculation and allocation, security specification, etc. A subtask is the lowest common denominator of an activity.

It’s only when this project activity granularization is complete and structured that a project plan becomes a vital tool in the successful execution and completion of a project. The use of the terms "major tasks," "minor tasks" and "subtasks" isn’t the terminology of a formal project methodology, but a choice based upon my personal experience.

Project planning is a topic that contains many commonalities regardless of process or venture. While this project describes the establishment of a mainframe-based cryptographic interface oriented primarily to CICS Transaction Server, COBOL and MVS, the principles and concepts apply to all IT platforms. In fact, the project plan delineated in this article included tasks and activities involved in converting the client’s websites using different programming languages and software to enable cryptographic operations and PCI compliance.

Drilling Deep

Defining a project to a high degree of granularity has numerous, important advantages:

• It greatly improves project plan usefulness. By breaking tasks into their smallest logical units (run a job, create a definition, etc.), a project planner or system analyst/programmer is driven through a detailed examination of processes that reveal interdependencies, unanticipated requirements, prerequisites, etc.
• It greatly improves time estimate accuracy. The smaller the task, the easier to estimate its duration. Project planning tools sum individual subtasks to provide substantially improved time estimates for minor tasks, major tasks, and the entire project.
• It reveals workload allocation imbalances and uneven higher-level task assignments. Breaking a major task into subtasks clarifies the major task’s true scope. Management can spread workload more evenly, although skill sets also play a major role in assignment. This granularization reveals whether sufficient skills are available, or if it’s necessary to find additional help.
• It reveals product/process and applications changes, which in turn identify changed or new tasks. Installation procedures and product function change with release, as can product or application interfaces. Fleshing out project details essentially researches all aspects of these variations during the planning stage rather than deep into implementation, where these variations can be disastrous.
• Links to specific passages in product installation, customization and definition manuals or other sources like SHARE presentations, IBM Redbooks, etc., can be embedded in tasks. This information is useful in defining the project plan, and in performing the work. Having substantial technical background, I knew what information could save substantial research time for assignees to tasks.

Task Characteristics

Drilling deep is more than just identifying tasks to the lowest level of granularity. A task is more than a description of something that needs to get done; it’s a unit of information. It has relationships with other tasks, it may be conditional depending on numerous variables, it consists of a plethora of attributes, which may be specified or defaulted to determine task content. A task is analogous to a letter in a strand of DNA: It’s comprised of numerous aspects that combine to form a unit of information. It’s part of a larger structure, which directs the formation of a much larger accomplishment. Here are some key task characteristics that determine task information:

• Task description―This is a short, multi-word depiction of an action or small group of actions that accomplish a specified activity.
• Task sequence―This organizes work in the general desired or necessary order of completion.
• Task prerequisites―This further organizes order of completion in the form of dependencies, and has three primary materializations: One to one, one to many, or many to one. Only rarely may it be many to many, and if so, only in small numbers. This characteristic is implemented via a relationship called a link.
• Task assignee―This refers to the individual(s) assigned to each task.
• Task start and end dates―These values can be calculated by the project planning tool using estimated hours (more on this follows) and a specified length of workday, or they can be explicitly specified for deadlines and milestones.
• Estimated hours―This refers to the projected time to complete a task. The timeframe must be realistic; from my experience, it should be pessimistic by 15 to 20 percent to account for unanticipated obstacles. The person assigned to the task should conduct the estimation. Ideally, this individual should have experience at setting project timeframes. I’m quite resistant to having management estimate work. They often base it on their objectives and are only indirectly responsible.
• Completion amount―This refers to the percentage of a task completed. 100 percent means complete. The task percentages of all project tasks are calculated into an overall project completion percentage.
• Supporting information―This includes footnotes, document extracts and installation materials. Hyperlinks to references can also be built into a project plan; this can drastically reduce research time by providing access to relevant material with the click of a mouse rather than manual lookup.
• Task number―This is the number assigned to a task. Most project planning tools do this automatically.
• Deadlines―In certain cases, tasks must be completed by a certain date. These can be assigned.
• Other task specifications exist, but are usually unnecessary.

Project Plan Refinement

The project plan becomes a living document; it’s constantly updated during the project. For instance the kickoff meeting’s high-level project plan and associated materials allowed me to further enlarge and extend the plan. My next step was to peruse these materials and expand the project plan based on findings and project member input. This input was vital, because it wasn’t my project plan, it was the team’s plan. I not only encouraged input and suggestions, I demanded them. Their input and review at every step of plan creation was vital. It enhanced and improved the plan, it engendered everyone’s commitment, and it gave them ownership.

In the next stage, I embarked on an intensive research effort, gathering all available Internet-based or internal information and incorporating it into the plan. Product documentation was particularly useful because it contained step-by-step software installation and customization directions. For example, the CICS TS Installation Guide identifies and explains installation tasks, and product installation tools like CBPDO and ServerPac contain similar guidance. Other documents like IBM Redbooks and SHARE presentations can be incorporated into the project plan with hyperlinks. Additionally, most clients maintain in-house, customized installation information in documents or data sets that also gets inserted into the project plan.

The project is now ready for final review, usually in a meeting. All team members are invited; it usually takes a half-day or so. The project plan gets one last update based upon the group’s input. Then it’s time to get to work.

Achievement Is in the Details

There’s a direct relationship between effort expended in discovery and scrutiny of elemental PCI compliance project tasks and the success of the implementation. It's true for any project. Creating an efficacious and powerful project plan takes much more than just laying out a sequence of events needed to accomplish an objective. It requires in-depth, detailed study of every aspect of a project. I think of a sound project plan as a fountain of vital and essential information borne of much research and analysis. I'm not saying it needs to be fancy and sophisticated to be effective, but it should be rigorous and consistent. It needs to be usable, and it must be comprehensive.

---