Humpty Dumpty’s
Secrets of Large Project Management
Eric Rosenfeld
Adaptive Consulting Partners,LLC
Humpty Dumpty: Tragic fairytale figure or poor project
manager? The picture we envision is that of a huge egg-like
character, the essence of fragility, perched atop a
treacherously thin wall, then suddenly toppling over and
falling to his demise on the rocky ground below. This is
real Steven King stuff! Truly, we all know of failed
projects. We all know project managers who have fallen, like
that famous egghead, only to leave an irreparable mess on
the ground beneath them. Sometimes, even lawyers (let alone
horsemen) can’t pick the pieces up – except
perhaps to make omelets for themselves, if you know what I
mean. Project management, if done recklessly can render a
manager as fragile and silly as that famous egg. Yet many
project managers continue to hang onto the habits that cause
their own fragility. Sometimes they are rescued mid-fall,
and sometimes not. I think it is time to address the problem
and save Humpty forever. "Poor Humpty!" you might say. As a child, I always
wondered, what was he doing on top of that wall to begin
with? You’d think that, as an egg with a pituitary
problem, he’d be a bit more careful. Perhaps he was
placed there, maybe even against his will. Perhaps he was
blind to his own vulnerability. Even so, why couldn’t
he hold onto something? If he climbed up to that perch, why
didn’t he look beneath himself, perhaps choosing a more
suitable, softer underlayment? Where were his friends at the
time? Didn’t his mother warn him about the dangers of
heights? These are reasonable questions, albeit a bit
strange for a child to consider. Questions have always been
the cornerstone of my personality, so I guess I was doomed
to be a consultant since early in my life. My consulting career has given me great opportunity to
observe organizations from both inside and outside and I
believe that Humpty is a fairly accurate metaphor for many
project managers. Project Manager Humpty failed for many
reasons, so this paper will examine the following: Teams are the reason for all project management, so it is
fitting to start by asking how you can build a better team.
Or friend Humpty had no team. When he fell, he did so alone
and to his own detriment. Not only was there no one to catch
him, but there was also no one to point out the danger. If
we assume he had no choice but to be up on that wall –
at risk – at least he could have surrounded himself
with good people to help out. Users and executive managers who do not understand the
implications or difficulty of what they ask have placed
untenable deadlines on all of us at one time or another.
Since IT exists to serve its business constituents, not the
other way around, we have all found ourselves with difficult
missions and no choice but to succeed. The goal, then, is to
build a team or set of teams that are impervious to the
capricious constituents they serve. However, a team is more
than simply a delivery vehicle for a set of programs or
other project outputs. The team should act singly to support
its goals and the manager who sets them. Therefore, I tend
to form teams around several guidelines: There are two main precepts I feel are critical for
successful hiring. First, each manager must recognize that
technical people are not all driven by the same factors, and
therefore each will be motivated by different things, and
seek happiness in different environments. Second, each
manager must recognize that the most successful teams are
made up of complementary personalities as well as
complementary skills. Personalities complement one another
when the goals and motivating factors of each individual
member do not conflict and the incentives set for the team
appeal in part to each members’ key motivating
influences. There are several basic motivating factors applicable to
everybody: money, position/respect, visibility, the chance
to do well, etc. The nature of these factors and how we
perceive them is a topic too complex to address in this
paper. However, recognizing that they exist and that they
can be used to your advantage is a primary consideration for
all managers who seek great teams. Incidentally, it is also
important to remember that positive motivation is almost
always better to apply than negative motivation, and it
almost always comes with less risk to the integrity of the
team. Sure, you can always fire or reprimand the team
members who don’t conform or act with the team, but you
might inadvertently send damaging messages to all of the
staff in the process. Everyone does both good and bad
sometimes and you can never be too protective about the way
the team perceives itself and its manager. Being negative
makes everyone weaker and more reactive, except in extreme
cases. The trick is to identify what each person really wants
and then make certain that there is no way that they can get
that at the detriment of the team. If one person wants only
money (in these times there are more of these than you might
imagine), you can suspect that they may become in conflict
with those who want visibility (or the chance to do other
things sometime in the future). One is focused on the
immediate gratification afforded by income, and the other on
longer-term career goals. This would especially become a
problem in a high-pressure environment. If the corporate or
project culture is highly short-term, the long term planning
type will almost certainly drift from the team and complain
about quality issues, while the short-term delivery type
will demand production at all costs. I’ve witnessed
this situation unfold at clients. If both individuals are
equally matched technically, this scenario might degenerate
into a war. Of course, there are exceptions to this rule: positioning
well and meeting project milestones can be both financially
rewarding and offer other opportunities. However, if a
person’s primary focus is not met at all points in
their tenure, they may drift away from the group and cause
the group to weaken overall. Since we all are influenced by
a combination of drivers and motivating factors, we need to
recognize that it is the prevailing factors overall which
will most influence the group. You need both types on your
teams (in my example). Hence, given this example, try to
find planning types whom also need some short term interest
satisfied. In summary, in order for the team to "gel," it must be
composed of complementary personalities. Regardless of
whether it is a team of consultants or employees, or some
mix of the two, each individual will require a niche. This
niche may be defined either by the work itself or the
individual person’s social skills. Therefore, it is
vital that the team is formed deliberately, if at all
possible. This does not mean that you have to screen each
candidate through some elaborate (and possibly illegal)
psychiatric test. It means only that you simply cannot
ignore that a team is composed of a set of styles as well as
a set of technical expertise, each person contributing part
and shaping the personality of the group overall. You would probably never hire an employee without a
personal interview. The interview process is invaluable
because it allows a manager to directly observe each
person’s reactions, demeanor, appearance and
confidence, in addition to showing that person’s
technical skills. Never hire a project team member without
an interview. Regardless of whether the new member is a
consultant or a long-standing employee, each needs to be
screened and placed onto a team that matches their
abilities, interests, and personality. Since interviewing is
an art, I highly suggest that this process be made as
rigorous as possible and held to standards. In order to discern which prospective members to "group"
into teams, I ask each candidate to rate their most
effective influencing factors. This is useful even given
that each person will use different terms to describe the
same basic things. In this, I always focus on short-term
motivators, since this is the timeframe where they will
effect my project. In fact, I sometimes use this information
to form their compensation plan for their first year. As I
need to form the team, I consider each ranking and compare
it to a statistical "group profile" to determine the "fit"
of each person. A person fits the group profile if their
basic rankings mostly match those of the other
members of the group. This also entails creating the team
all at once (more about that later). I use a similar tactic to assess the fit of each
person’s technical skills. Each new candidate is given
a standardized test, which covers basic technical skills.
The candidates’ are ranked according to their score and
interviewed in that order (best score first). Since
technical prowess is key on an IT project, I am careful that
each candidate has the same average score, within less than
one standard deviation. The team members whose mean technical scores and
motivator rankings match the average for the team will be
most successful. By following this guideline, you are less
likely to staff a prima donna, or someone who feels
they’re too good for the group. Finally, it is critical for you to recognize that each
team will have a nominal leader, regardless if its manager
asserts one or not. If the manager chooses and depends upon
the same person that the team agrees is its leader, there
will be far less conflict on the teams and the teams work
will be far more consistent. If the work done by the team is
technical, often the team will choose its most proficient
technical guru as its leader. In all cases (and this is a
good check on your group formation) make sure that the
leader has as close to the mean scores across the board as
possible. Let the team choose its own leader as it sees
fit. The bottom line: form teams by engineering them and
you’ll end up with better teams. Motivate your teams
positively and with knowledge of each individual’s
goals and they’ll come together without your
intervention. If you’ve got to be up on that wall, make
sure you’ve got a good team under you. Getting back to our metaphor, Humpty is now on the wall,
and he has arranged a great group of people underneath him
so that, should he fall, there will be someone to catch him,
or at least call 911. Or has he? Sure, the groups is formed,
functional, and friendly, but are they focused enough to
recognize the first signs of trouble and move under Humpty
effectively? The keys to focusing a team are fairly straightforward.
Briefly, keep the team small, keep the goals simple and
understandable, and keep measuring the team. One more rule
is crucial: Don’t allow the team to waste its resources
on anything that doesn’t directly bring about their
objectives. There are a number of case studies that support small
team size. Communication, which is vital to team success, is
easier and simpler between small groups of individuals than
amongst larger groups. IT demands creative people.
Unfortunately, creative people often proffer multiple
opinions, sometimes simultaneously, when confronted with
issues. Hence, excessively large numbers of creative people
all attempting to work together on the same level, tends to
result in chaos. A complicating factor is the overall
arrogance of some highly talented IT professionals –
which seems large and is apparently growing. These people
tend to cut themselves off from others who do not share
their stature (as they see it), thus making it even harder
to control a massive team. How many large projects do you know that failed? The
number of small, grass-roots projects that failed is
probably far smaller. The ones that did fail probably did so
on a smaller scale, with fewer repercussions, and less blood
on the floor. There was less money involved, and a smaller
scope at stake overall. Keep the team size small and you
reap the same benefits: the risks of failure are smaller and
the fear of failure is correspondingly small. Fear is a big
negative motivator of teams. Metaphorically, if you reduce
the size of the wall, Humpty has less distance to fall. You
also stand a better chance of catching him. As a guideline,
I try to limit each team to five members. The mix of skills
is determined by the work at hand, but the number of players
is constant. Secondly, set the team’s goals for completion in the
short term. This entails defining the rough "big picture" or
overall project plan before chartering any of the teams. By
setting short-term objectives and keeping the deliverables
of the team well defined, you build a sense of confidence
amongst team members that they can immediately apply to
solving tough issues. Each team I charter has defined
deliverables and a six-week plan at most. In chartering the teams, keep the charter simple. For
example, a team that is chartered with an entire subsystem
may not know where to begin functionally, and stands a
larger chance of approaching the work inconsistently with
other teams’. If an entire project is chartered this
way, there is an excellent chance that system integration
will not occur until the very end of the project, and then
chaotically. If your project goals for any team cannot be accomplished
by five people in six weeks, they are probably too grand.
Break up the goals in order to create interim deliverables,
or charter parallel team efforts and you have a better
chance for success. If you try to manage everything at once,
you’re inviting trouble, at least in my experience. If
you have to charter multiple teams, make certain each team
is deliberately phased and that the interdependencies
between team efforts are well known. Don’t expect the
teams to identify this by themselves, especially in a
multi-team project. Left to their own devices, teams do not
tend to organize their work for the greater benefit of the
project. Therefore, charter all interdependent teams at the
same time, staff them together and organize their work
products at the same time. I have found that the key to successful projects on a
grand scale is my (or my clients’) ability to form
several small teams quickly, synchronizing their work scope
and quality as they progress. After-the-fact integration
seldom produces good results because integration of systems
is a detailed task, effecting programming and testing. Letting the work define the
team Many managers assign work to an established team,
expecting the team to orient itself and assign roles to
realize their objective. I find it easier to form the team
using the old "Mission Impossible" approach. Once I have my
marching orders, I choose from my available talent pool to
custom-fit everyone who will work on the team. Each person
is carefully considered based on their interests, skills,
and accomplishments. Because I choose the talent to fit the
problem, I have a better chance that each of my team members
will function as expected. If I were to assign the same work
to an already established team, there would be a higher
chance of failure because I couldn’t control the group
dynamic or balance between members. I highly recommend that each IT manager keep a pool of
resources since it allows him more flexibility, and forces
each prospective staff member to be aware of his/her
potential value and to compete to become part of key
projects. Even in corporate environments, where freelancing
is not accepted, organizing IT staff into "pools" afford the
manager a better ability to mix and match styles and develop
maximally efficient teams on an ad hoc basis. I believe that
people are at their best when they are in competition,
especially competition based on their innate abilities and
learned skills. Any work that does not directly result in progress
towards team goals is a potentially misguided or wasted
effort. I believe that the purpose of a manager is to
ruthlessly and tenaciously eliminate all obstacles that keep
each team from its stated objectives. The time, for example,
programmers spend preparing long winded, written status
reports, attending status meetings, and writing or reading
heaps of e-mail, is generally wasted, at least with respect
to the teams’ goals. It is easy to consider that they
would be better serving their employer if the team members
used that time instead to research, design, implement and
test programs. Unfortunately, this common sense is not
applied very often. Unnecessary meetings and information
gathering are two of the largest obstacles to success most
managers impose on their own teams! I’ve found that teams can easily get into trouble if
they are doing work that they shouldn’t be doing. By
gathering information for their manager, their focus is
unintentionally diverted. Granted, status reporting is
important, but short status reports can be obtained through
the managers’ day to day involvement with the team, and
briefly summarized by the manager themselves. Since I spend
most of my time managing teams, I make this recommendation
despite my own hatred of paperwork. However, I believe that
it is the managers’ role to run interference for the
team: As a manager, I try to ask myself one question about each
task I assign: "What am I trying to accomplish?" Where
status reporting is concerned, I am obviously trying to
detect, at the earliest possible moment, if the schedule
will slip or the quality of my product diminish. In order to
accomplish this objective, I have to ask myself one more
question: "How can I achieve this without hurting the
team?" Clearly, asking each member to account, in detail, for
each hour of the week by forcing a written status report
from each of them will be destructive. Firstly, the process
of status reporting is demoralizing, especially if problems
exist. Secondly, I do not necessarily care about how much
time they are spending (within reason). I care instead about
making demonstrative progress and identifying
problems. Hence, I like to keep status reports short and
simple, often asking each member to do two things: I can gauge the status of a project simply by assigning
these two tasks. I know what is being accomplished and I
have a chance to head off any looming trouble before it
causes my project to delay. If a problem exists that I
cannot handle, I can send the message to my superiors
directly, exempting the programmers altogether from that
chore. By the way, these two recommendations have secondary
benefits. First, the team has an improved sense that the
project is going well and so morale and productivity stay
steady (or increase) as the project progresses. Secondly,
problems that do arise can be used as learning experiences
for both the member who identifies the problem, and myself.
Once problems arise, I can walk through them with the team
member to find a solution. In fact, even if I wasn’t
predisposed to do this, the fact that the member approached
me with a problem makes it difficult to ignore him/her. Most
managers can easily ignore problems if they’re merely
stated on paper. One final word on productivity: choose tools that enhance
the productivity of your team and work that tool rather than
letting it impose its work on you. In short, choose tolls
that complement your work content and style.
Documentation, for example, can be produced largely using
packaged applications, especially if you’re using a
database CASE tool, such as Designer/2000. I have been using
one such product, "Publisher/2000" (produced by Solutron,
Inc) which has greatly decreased my need for documentation
which may have side-tracked my developers. I have used this
tool to pull information from the CASE repository to produce
Microsoft Word documents directly. With a small amount of
editing, I can basically produce most of my "as-built"
documentation without the aide of a programmer! Obviously, I
need to involve others in the documentation process, so the
tool does not completely remove developers or QA personnel
from the chore, but it dramatically reduces the amount of
time they need to spend at the outset. In summary, if I’m up on that wall (remember
Humpty?) I want to make certain that I have the best team
under me and that the wall I sit upon is as broad as
possible. I ensure the resiliency and capability of my team
by engineering them for the task at hand. Furthermore, I
broaden my wall (probably shorten it as well) by breaking
the project itself into small tasks to be delivered by small
teams. All in all, by following just these precepts,
we’ve added years onto Humpty’s life expectancy
and reduced his insurance rates for good measure.. There is a key motivator inherent in the way I build
teams: wanting to be staffed on the next project in the
first place. As I’ve already described, if you form
your teams with a very specific purpose, and keep them
highly functioning and driven by discrete project
milestones, you will force an issue of quality amongst your
staff. The mere competition for placement is a strong
motivator. Aside from the cachet of being part of an elite team, you
should accept that most professionals will do what they have
the opportunity to do and know how to do, if it pays off for
them to do it. In fact, I find motivation is a quality that
is hard for a manager to instill, if it is totally lacking
in the individual in the first place. So if you: you will not encounter motivational problems, despite the
size of the solution you are trying to achieve. In fact, if
you treat large project goals as sets of small ones, as I
indicated above, you should eliminate the de-motivating
factors caused by your teams’ fear of failure. If, despite the size of the goals, you still find that
the team (or project) has poor performance, it is likely
because you have either organized, communicated, or reviewed
the work in a way that is actually causing the problem. In
this case, don’t be fooled by the few individuals who
consistently perform well. Instead focus on the incentives
and make sure the goals are well understood, even
documented, prior to the next assignment. In cases like
these, you should talk to the staff – they will likely
know exactly why they have a problem. To set incentives, consider the effect of doing good
work. If this is a development project, what is the net
effect of the system? Usually (unless you work for a
software manufacturer) the goal is not to simply finish the
product and ship it. The real "win" occurs after the product
is finished and in use by the customer/client.
Therefore, set the incentives to coincide with the
real performance indicator – the acceptance of
the system by the client. In general, you want to set
positive incentives so that the employees share in the
profits of their own labor. Under tight deadlines, for
instance, I usually give incentive bonuses for getting
things completed early provided that the work meets
all the normal Quality Assurance standards of the project
and it is accepted by the user. I also use
non-monetary incentives like Friday evening happy hour and
other social events, if I feel that will appeal to the
staff. In the best circumstances, a manager can actually build
upon the initial cachet of the team by trumpeting its
ability to meet deadlines no other team can meet. Team
Identity and pride are self-fulfilling attributes which can
be exploited for both the good of the team and its
manager. Let’s review where we are: We’ve set the wall
on which Humpty sits lower and broadened it by limiting the
scope of a project or breaking a larger project up into
pieces. We’ve spread a safety net below that wall, and
populated it with efficient teams who can hold it up.
Finally, we have made it less likely for anyone to push
Humpty over, since we’ve raised morale, made the
project more effective, and given him the ability to see
trouble coming. But trouble may still come. We need to give Humpty
something more to hold onto than just the wall itself. At
this point, I am turning my attention to systems development
projects exclusively. In my opinion, the handle you need. if
you are developing commercial computer systems, is called a
Computer Aided Software Engineering (CASE) tool. CASE tools
are invaluable resources of project and system information
which can serve a savvy project manager by indicating
status, quality, and even the sequence of project tasks to
be undertaken. You just need to know where to look. Designer/2000 is an example of a CASE tool that
encourages team support and acts as a repository for shared
communication amongst teams, users, and management alike. In
short, Designer/2000 is a great tool. However, it is not a
panacea. Simply having and using it doesn’t by any
means guarantee a project’s success (sorry Oracle). Like any development tool, Designer/2000 needs to be
properly implemented in order to be maximally useful. In
this case, it means implementing the tool and
adopting a suitable Systems Development Lifecycle
Methodology (SDLC) simultaneously. You cannot adequately use
the Designer/2000 CASE tool without also adopting a method
that forces development teams to use that tool effectively,
with discipline and rigor. There are several suitable models
to choose from, most of which involve some form of
Information Engineering. It is beyond the scope of this
paper to discuss these methods, but here are a few
requirements for any method you adopt: The benefits of CASE to a well prepared manager are
legion. There are so many benefits, I could not hope to
mention them all in this paper. However, I will share some
important, sublime uses not normally discussed in the
average CASE sales presentation. One way that a CASE tool can act as a handle for a
project manager is its ability to assist in the sequencing
of project tasks. In a complex project, it is often
difficult to know which subsystems to create first and which
modules in those subsystems to create first. One trick I use
to determine sequencing is to inspect the project’s
informational requirements and begin system development by
focusing on the programs which manipulate the most
referenced (or definitional) entities. As most experienced analysts know, an Entity Relationship
(ER) diagram is an invaluable tool. It graphically defines
information which is crucial to the enterprise (or system)
under study and organizes, categorizes, and defines the
relationships between those elements of information. With
one glance at the model, you can discern the basic
relationships and definitions of data. If it is organized
correctly and according to common standards, the diagram
will display the data which is most basic, most often
referenced and fundamental in one corner of the diagram. As
a result, system development may be facilitated if the
effort is organized around the data itself, beginning with
the lowest order of "reference" data, and continuing through
layers of "transactions" until the whole model has been
serviced. Hence, the system development effort evolves as
the system itself takes shape. The focus of the team can be
shifted, literally along a diagonal line across the diagram.
First the most basic forms are created to service the
reference data. Perhaps the data conversion efforts are also
started at the same time. By the time the transaction levels
are done, the developers have test data, and the code they
write is based upon solid foundations, namely because the
underlying code has been finished, tested, etc prior to the
more complicated tasks. Another good use of information in the CASE tool is to
support the development of test scenarios and system test
strings. The CASE tool, especially Designer/2000, holds much
information about the way a business uses a system.
Specifically, using the Data Flow Diagram and Business
Process Engineering diagrams a manager can scope and define
system test and acceptance scenarios. In addition, the
constituency of a particular module may be traced from the
module to the function it implements and then to the
business unit, data store, and flow imposed by a particular
use of that module/function. In any event, it becomes clear
that the module is an implementation, for a specific
purpose, of a function as defined by a user. With that
knowledge, it becomes far easier to define acceptance
criteria and external test criteria for the program. In
fact, using the CRUD matrix for that function (i.e.,
function / entity usage) and considering the entity to table
mappings which are done as a part of the database design, it
is possible to define system "strings" or groups of related
modules to test together. Basically, a string is defined as
the set of modules that shares either functional flow, or
common usage of a set of tables, generally in support of a
single, well defined business function. Once you know where
to look, the system and string tests can be made far less
cumbersome to develop. Hopefully, that also increases their
quality. One area of general concern for managers is their ability
to predict the timing of system development tasks. The
Designer/2000 tool can also assist here, since it is
possible to use the tool alongside time tracking tools to
define baseline metrics for a team in development. The
mappings can be easily turned into quantitative measures by
simple counting or weighted counting of tables, columns, and
procedures to be called or managed within any given program.
Each program can be given a numerical weighting based on
this analysis, and barring any other complex algorithms, can
be compared to actual performance to define how long it may
take a programmer to finish a new program, or how that
programmer’s productivity compares to the average for
his/her team or project. Since no new feature is free, this
will enable a manager to identify time and cost consistently
and therefore with some credulity. Finally, I try to make the analysis and other outputs of
the development effort open to all users whom I am serving.
I can, with the help of a few third party tools, publish the
information from the repository onto a corporate Intranet.
In this way I use the case tool to answer simple questions
about the project and its product. I can deflect any
interruption by the users for simple information, and I
protect the team from distraction by doing so. In addition,
I use the tool myself, if I ever need research material on
the project or its status. Since every report I ask team
members to write has to be worth the time it takes to write
it, I use the CASE tool on those issues where I can do the
research myself, leaving the writing to more important times
when I really need it. In order to use the tool in this way, it is imperative
that all modules be identified in the tool even if
they’re not to be generated directly. This affords
completeness to the effort overall, and increases
communication about which code performs which function, and
so on. I also try to develop application fragments in
separate Designer/2000 Application Systems. Each team works
in their own application system and shares database
components from a central, separate application. This may
seem cumbersome at first, but it has the advantage that the
applications can be seen as objects and built into a
hierarchy. It is also advantageous since I always try to
keep the revision level of the CASE application system and
the source code control manager (like PVCS) equal. Different
application fragments will require revision on different
schedules, and this technique allows me greater flexibility
overall. It also offers better clarity since the
applications’ modules are categorized and packaged
separately. In summary, in order to save Humpty Dumpty, you have to
insulate him from the danger and lessen his chances of
falling off the wall. We cannot change his basic nature (he
is a fragile egg), just as we cannot change our own. Project
management is risky because it is a focal point of delivery
for a system, or any other key objective for that matter. It
is the very essence of the "hot seat" and will likely remain
so. To limit the risk and ensure your success be sure
to: Make the tools you use a centerpiece of the project. CASE
tools can keep the project stable, documented, and
organized
Humpty Dumpty had a great fall.
All the king’s horses and all the kings men,
couldn’t put Humpty together
again.