Reverse Engineering & the Zachman Framework

"The FORS  system has been around so long, how are we ever going to replace it?” was the question from Amy, the Finance Director.  She was talking with Jorge, her counterpart in IT who managed the financial applications.  They had both been with the company for years and the application had been in place when they arrived.  “The COTS replacement is going to streamline maintenance and support going forward”, Jorge responded “but we’ve made so many client customizations to manage quality in our field offices, it’s going to take forever to extract all of the unique business rules.”

In a previous millennium, I was a participant on a Y2K project to replace a legacy application written in a source language that was (even then) no longer supported.  The vendor was commissioned to rewrite it – which really meant reverse engineering the requirements and specifications.  I was introduced at that time to the Zachman Framework.  I appreciate closed methodologies (that is, a specification that is comprehensive and fully integrated).  Further, I think hierarchically.  The Zachman Framework was a golden find and we utilized (a variant of) it on that project.

Later, I had a similar opportunity when I was managing a small development team responsible for a legacy application that was also a strategic enterprise asset.  We utilized the Zachman Framework again to document the reverse-engineered data model, application architecture (component interfaces), technology architecture, business rules, event model (triggers), user interface, and role model.  The key was that we were able to separate and clearly distinguish the logical model from the physical model – that is, the business requirements from the technology constrained implementation.

The one difficulty I experienced was getting my team to buy in to the need to document the system.  As their bread-and-butter, they didn’t want to make it easy to replace it.  As long as it was a black box, they felt their jobs were secure.  As it turned out, I believe they are all (except for me) still there supporting that system.  Such are the ways of corporate enterprise.

Nonetheless, for documenting and understanding enterprise systems, I am a big fan of the Zachman Framework and am glad I have it in a slot in my toolbox.  While it is applicable to a variety of circumstances, it is a lifesaver when it is time to “rationalize” that critical legacy application. 

Heroes

“Let’s give a big round of applause to Jeff for saving the eXrel project.  It looked like a doomed effort until he stepped in and saved it for us - again.  This is the third major project Jeff has salvaged in just two years.”

You do need to publicly recognize your team members who go the extra mile, but if your shop relies on heroes repeatedly, you need to step back and evaluate your operations.  After all, this describes the chaotic environment that defines a maturity level 1 organization, where success is dependent on spectacular saves, monumental individual efforts, and the performance of key personnel.

Therefore, while you as a manager should recognize and reward your heroes, you should be asking why you are dependent on them and what you can do to sever that dependency.  After all, there is a better way.  Higher maturity shops operate in a more consistent, more reliable mode.  In fact, in higher maturity organizations, there is rarely a need for heroes.

I can hear some readers saying that is because they plan better, and, while that is a true statement (if only because it is a tautology), it is more accurate to say that they can deliver to their plans.  That is, they have a delivery capability that is reliably consistent and can be modeled successfully and the model will include the elements necessary for successful delivery.  Their plans are realistic models of their actual delivery rather than the optimistic hopes and wishes of the planners dependent on good luck and herculean efforts of team members to bridge the gap between hope and reality.

So for executives as you observe, analyze and review your subordinate directors, divisions, managers, and departments, notice the ones that recognize their heroes.  Those are the departments that probably need the most attention, coaching, and guidance to mature their operational processes.  They are also the departments where you stand to gain the most from making improvements.

Planning

“Why does it seem that every one of our projects takes forever just to get out of the blocks?” asked Jack, Executive VP, HR.  Jack and Diane (apologies to Billy Joel) were having lunch at their favorite Italian restaurant and discussing the latest reorganization plans.  “I’ve never thought those IT guys were all that efficient, with all of their documents, checkpoints, signoffs, reviews, and meetings.  But they can sure get a project up and running a lot quicker than any other division.”  “It is strange,” responded Diane, CFO, “that we’re always complaining about how long it takes IT to finish a project, but we get grief for how long it takes us to start one.”

Planning is actually much easier in a shop that conducts many, similar projects and uses a standard project delivery methodology.  The corollary to this observation is that shops least qualified to plan are those that need planning the most.

These maxims are almost self-evident.  After all, when an organization has performed enough projects to build project delivery expertise, standardize their methods, tools, roles, and deliverables, and wean out the sources of failure, people know what to do, how to do it, and when.  Expectations are stable;  misunderstandings are reduced.  On the other hand, shops where each project is a novel endeavor have to negotiate roles and responsibilities from scratch every time and don’t have the luxury of knowing the best paths for avoiding project calamity.

These shops need planning the most, but, not knowing how much they don’t know, miss key elements.  It’s like a phonograph needle (remember those?).  An old, dull one sort of bounces off the top of the grooves while a new, sharp one gets into all of those little pits and pockets, giving a much more robust (and potentially noisy) experience.

So, should your shop commit the effort to plan or not?  There are two responses to this:

1)      Why bother?  After all, it probably won’t make much difference?

2)      Of course, because the project will turn out even worse otherwise.

Some might say that the best predictor of a successful project is good planning.  I say the best predictor of project success is having delivered lots of projects successfully.

Maybe that’s why a veteran project manager is so valuable.

Resource Management Maturity

Linda, the operations director, was again reviewing reports with her development manager Dennis.  “I don’t understand why we continue to have this rolling bubble of demand in the next two weeks, then it drops off to nothing after a month?”  The report Linda was reviewing was the resource demand report.  “Every time we run this, no matter how much effort we’ve put into planning our resource needs, the report always shows we need 200% or 300% of our capacity for just the next couple of weeks, but then it rapidly drops off.  But when we actually perform the work, we have adequate resources, but then the bubble shifts out in front of us again.  What is going on, Dennis?”

Planning and scheduling for resource demand is always challenging.  Just a few years ago, there were shops operating with excess headcount.  Tales from those days might be mythic lore to today’s project teams.  Some organizations are running well below necessary headcount.  Getting projects completed while keeping up with support and maintenance demands requires constant rejuggling of priorities and resource assignments.  People multitask.  Team members are whipsawed from one must-do yesterday to another gotta-have-it-now today.  They are heroes in their organizations, but this is nonetheless poor management and inefficient use of people (though, having been there, it still sometimes beats the alternative).

Interestingly, we can use these examples as heuristics to suggest the organization’s maturity level.  For example, the organization that is scrambling, doesn’t know who is doing what, and is constantly changing assignments and priorities is clearly a Maturity Level 1 organization.  A Maturity Level 2 shop is managing the portfolio of projects, initiates projects based on priority, has basic metrics (task estimates and resource usage), and generally has people assigned when and where they need to be (projects advance based on real-time availability), but limited predictive capability for planning what projects can be delivered based on resource capacity.

A Maturity Level 3 organization has reliable task effort estimates, team members report progress by updating their hours by task and re-estimate the remaining hours, resource schedules are based on productive effort, all resource hours are tracked (project, support, maintenance, admin, vacation, training, etc.), availability is projected based on historical trends, statistical allocations, and planned absences, so that theoretically management can predict which projects can be staffed.  The reality, though, is the situation Linda and Dennis find themselves in.  All the numbers are there, but there is still a fog of misinformation that separates ideality from reality.

Future posts will describe Maturity Level 4 and Maturity Level 5 organizations and address why Linda and Dennis are operating in a fog and what they can do to find the sunlight.

In the meantime, which example best describes your organization?  Do you see value in raising your organizational maturity?

Communications, Communications, Communications

It seems appropriate to initiate a blog about project management best practices with a discourse on communications.  I certainly have plenty to communicate.  I look forward to sharing my thoughts with you.  May you find some of them interesting to read.

The description of this blog documents my intent and will drive the selection and direction of content.  I will present here my thoughts on PM best practices;  I invite your feedback, critiques, support, and disagreement so that we share a discussion;  and I hope that from my humble contributions someone finds a gem and takes a step to improve their organization.

So what does “communications” have to do with best practices?  Communications isn’t a best practice.  Communications is just sort of what happens when we project managers do what we’re supposed to do.  Publish a project schedule?  That’s communications and fosters communications – team members and stakeholders either accept it or they object, and the ensuing discussion improves the schedule and everyone’s understanding.

Project plan (and, notice that project plan is different than the schedule).  Negotiating the plan (and the component plans for managing costs, resources, risks, vendors, etc.) causes team members and stakeholders to understand how each role contributes to the ultimate result.

A well-prepared project status report is a key communications tool, providing a snap-shot of the project state (relative to plan), accomplishments, issues, etc.  The status report is like a diary, providing a continuing narrative of the project state.

The risk register, issue log, change requests, EVM graph, deliverable acceptance form, and everything we as PMs produce are just there to force two or more people to see the same content presented in concrete form and either accept it or talk.  By publishing the content, you prevent misunderstandings and misaligned assumptions.  I’ve been amazed over the years how many project problems have been avoided just by forcing two people to talk to each other.

Each of these documents are best practices for a reason – projects work better with them.  They’ve been proven by experience.  That is, when they are used projects are likely to be more successful than when they are not used.

So I’m going to communicate.  I’m going to share what I’ve learned.  Maybe somewhere in my ramblings you’ll find a gem that helps you on one of your projects.  Until then…

Communicate, communicate, communicate.