Skip to main content

Tokenized Encryption: The Project Nexus

The project generating this article largely involves implementation of a mainframe-based cryptographic interface oriented primarily to CICS Transaction Server, COBOL and MVS. However, these principles and concepts apply to all IT platforms. In fact, the project plan includes tasks and activities involved in converting the client’s websites using different programming languages and software to enable cryptographic operations and PCI compliance.

In preparation for this article, I searched “project planning” on the internet and got pages of hits on tools, methodologies and products. I then searched “project plan tracking,” which led to a handful of mostly vague hits on its value (although there were a couple very well-written articles on methodology and benefits). This confirmed my suspicion that there are all sorts of vendor and consultant sites about plan creation, but only a few actually discuss plan usage. Ironically, even if you do all due diligence—drilling down to the tiniest detail, carefully reviewing the plan with all participants and relevant management, in short, doing all the right things to produce a comprehensive and superior plan—but fail to use the project plan to run it, even the finest plan isn’t worth much.

A project plan is of little use if it’s not the project nexus—the guiding light to all project activities, prioritization, sequence, timing, interdependencies and critical paths. A project status meeting is what gives the plan its steering wheel, its gas pedal, its GPS and its warning lights. This is especially true for complex projects such as a payment card industry (PCI) compliance conversion where new technology needs to be implemented, hard deadlines must be met, multiple applications are impacted and require modification and the company’s future depends on its success.

One past article discussed a two- to three-day kickoff meeting with all project participants collaborating to create a high-level project plan. Another discussed the use of many small meetings to flesh out task details necessary to transform the high-level project plan into a living, effective project plan. You can also have a mid-sized, weekly project status meeting; this is the element that turns a project plan into a project nexus. This type of meeting is attended by project members who review progress, engendering questions like: Who’s doing what? What’s running behind? Who’s waiting on who or what? What’s taking more time than projected? What obstacles have arisen? Who needs help and when? What needs to be added or removed? What should I do next? A successful project status meeting reveals the answers to all of these questions and more.

Project Status Meetings

The project status meeting enlivens the project plan. While these gatherings are typically weekly, the frequency can vary based on activity, critical issues, urgency, looming deadlines and/or milestones, etc. Meetings usually last between one to 1.5 hours, and a schedule helps staff members plan their time. It’s imperative for the project manager or assistant to keep things moving, limit needless discussion and address important issues while involving all participants. It’s a sizable time commitment, so it needs to be productive. A project secretary should also attend to record activity and discussion.

Here’s an overview of status meeting flow:

  • Roll call. List and record all participants in attendance
  • Discussion of previous meeting follow-ups and issues. These come first because they affect the remaining discussion; unanticipated issues always arise during a project, estimates are wrong, plans get changed or something fails. For example, a vendor software code defect might require vendor action before installation proceeds. On-order disk drives might be delayed, preventing test database creation, compounded by hardware installation that must occur when the system is down or at low activity. Or, a system programmer might have health issues. Whatever it is, open issues often require management along with monitoring, vendor involvement, financial justification, or special scheduling—all of which cause significant delays
  • Project plan review. This often starts with the oldest incomplete tasks, although if certain individuals need to leave early, get interrupted by a hot call or something similar, rearrange participants’ sequence. Each individual will review tasks that are completed, in progress, irrelevant (i.e., task is marked complete, taking zero hours) and—on occasion—reopened. Hours should be discussed in terms of percentage complete and are reported with timesheets. At times, a task requires additional discussion regarding new function, a software change or a surprise discovery. It’s incumbent on the meeting moderator to limit these discussions. Meanwhile, the meeting secretary updates the plan and logs important comments.
  • Circulate final updates and timesheets. Since timesheets are often weekly, Thursday is a good day for a status meeting. (Fridays are often used as days off.) Once the secretary compiles meeting minutes, receives timesheets and finishes project plan updates (which may entail some calls or one-on-ones for clarification), the two documents—the project plan and the meeting minutes—are sent to all project members. Members then review the project plan updates and documented meeting minutes, responding with corrections so a final update can be performed. The final updates are typically circulated on Monday or Tuesday to all members and other relevant parties.

The status meeting isn’t the only interaction between project team members. Quite the opposite; it’s the catalyst of project activities, communication, sharing and collaboration. If someone in the meeting is behind or needs help, a teammate may offer to lend a hand. If a vendor needs encouragement, the CIO might offer to make a friendly call. Two products might have complementary parameters, so two systems programmers meet to figure it out. If someone discovers a neat trick with a system tool, they pass it on to the group. All kinds of interactions are initiated during a project status meeting; it fosters frequent communication that generates action, a sense of purpose, unity and ownership.

A project status meeting often creates requests for other meetings to address more specific project issues (e.g., change management, problem management, security management, hardware planning). In turn, these meetings generate reciprocal input back to the next project status meeting. The project review process ensures that proper systems management procedures are followed. It also assures correct forms with the necessary approvals or signoffs are submitted within appropriate timeframes and directed to the proper group leaders.

Because status meetings keep the project plan current, queries on project status—whether they come from upper management, end-users, clients, customers or regulatory agencies—are easy to provide. You can generate a general estimate of project details, keeping in mind that it’s subject to change. Project newsflashes update other departments, clients and customers about milestones, times of interrupted service, cutover plans, and standards or guidance checklists, depending on who is affected by what. As these events occur, they’e added to the project plan and individuals are assigned to their production.

Tracking Progress Means Success

Project status meetings can bring a project plan—specifically a project nexus—to life. When this plan is used to direct and control the project, it becomes the central focus of the project itself, providing vital direction and control. A plan that’s consistently updated as a project progresses, and always reflects the current state of the project within three to five days is a powerful tool for effective project management. Interaction and communication between team members is greatly enhanced because the project status meeting provides a “meeting at the water cooler” atmosphere, enabling technical consultations while facilitating side conversations.

Since meetings can be held as a teleconference, most participants don’t need to leave their desks or homes. While technical qualifications must be considered, management is consistently informed when resources need to be reallocated, priorities need to be changed, optional activities should be deferred or if any of a plethora of other adjustments need to be made. Every participant is fully informed of the project’s status, allowing everyone to maintain a sense of ownership and commitment. The constant flow of information also facilitates high quality decision-making. Project status meetings combined with a comprehensive and detailed plan is what determines a project’s success—something that, for critical projects such as PCI compliance, also decides the success of an entire organization.