| Project Management |
| Managing a Project |
Project Management is both a science and an art form. The skill set required of
a good project manager are logic (to see completeness of the specification),
interpersonal skills (to engage the project stakeholders and manage the
implementation team), more logic (to see how the resources are dove-tailed
into the project flow), and appropriate mindset (either a cautious optimism or a
manic pessimism). A good project manager should memorize the following
books:
I have numerous years experience in project management and here are
some tips I have learned the hard way.
a good project manager are logic (to see completeness of the specification),
interpersonal skills (to engage the project stakeholders and manage the
implementation team), more logic (to see how the resources are dove-tailed
into the project flow), and appropriate mindset (either a cautious optimism or a
manic pessimism). A good project manager should memorize the following
books:
- "Wicked Problems, Righteous Solutions" by Peter DeGrace and Leslie Hulet Stahl
"The Mythical Man Month" by Frederick P. Brooks, Jr.
"Death March" by Edward Yourdon
I have numerous years experience in project management and here are
some tips I have learned the hard way.
| Professional Engagements |
When the bank realized that a competitor was rolling
out a new consumer product, our bank panicked
and insisted on a similar product. I was invited to
manage the 'Front End' development of the product
while design and functionality were still being mulled
over. Discussions of design and functionality
continued, of course, well past our roll out. My job
consisted of participating in the design and
functionality discussions, bringing the latest plans
back to the development team (of 34 professionals),
and dividing the work steps into meaningful
teamwork.
out a new consumer product, our bank panicked
and insisted on a similar product. I was invited to
manage the 'Front End' development of the product
while design and functionality were still being mulled
over. Discussions of design and functionality
continued, of course, well past our roll out. My job
consisted of participating in the design and
functionality discussions, bringing the latest plans
back to the development team (of 34 professionals),
and dividing the work steps into meaningful
teamwork.
Invited me to manage a project that had
developed paralysis. The technology and
implementation plan was reasonable. In my
developed paralysis. The technology and
implementation plan was reasonable. In my
Asked to create a Risk Management System using COTS
product(s). As the project manager, this meant to distill
the elements of a RMS into its quintessential components,
confirm that these components can be fashioned to
meet two or more individual risk discipline
requirements, create a Functional Specification
document, create a Request for Proposal based on the
specifications, select a vendor population, distribute
and evaluate responses. Then, go through vendor
demonstrations, select the top two players, create a
Proof of Concept (document, environment, execution),
move the proposal through technology, capital budget
and other committees approvals. Strong use of MS
Project, working with a varying crew of 3 to 5
contributors.
product(s). As the project manager, this meant to distill
the elements of a RMS into its quintessential components,
confirm that these components can be fashioned to
meet two or more individual risk discipline
requirements, create a Functional Specification
document, create a Request for Proposal based on the
specifications, select a vendor population, distribute
and evaluate responses. Then, go through vendor
demonstrations, select the top two players, create a
Proof of Concept (document, environment, execution),
move the proposal through technology, capital budget
and other committees approvals. Strong use of MS
Project, working with a varying crew of 3 to 5
contributors.
Director of Technology for a start-up software firm
specializing in financial services calculations and
acceleration products. Responsible for planning
the SDLC for an ongoing research engagement
that was continuously evolving. Coordination of 35
remote, international scientists and researchers
required 24 hour planning and control. Often, one
team would pick up the work of another and
continue ('following the sun'). Duties included
tracking, up-to-the-minute status, automated
testing in multiple platform environments, and
productization of the algorithms.
specializing in financial services calculations and
acceleration products. Responsible for planning
the SDLC for an ongoing research engagement
that was continuously evolving. Coordination of 35
remote, international scientists and researchers
required 24 hour planning and control. Often, one
team would pick up the work of another and
continue ('following the sun'). Duties included
tracking, up-to-the-minute status, automated
testing in multiple platform environments, and
productization of the algorithms.
 |  |  |  |  |  |
Not uncommon was the need to eat yesterday's plans or modify them.
Strong interpersonal skills on my part helped. The project was a success
based on a number of top-down principles employed and a great team.
Strong interpersonal skills on my part helped. The project was a success
based on a number of top-down principles employed and a great team.
| Major bank |
| Major bank |
first team meeting (to learn the 'state of the project'), I
discovered strong animosity between two very strong
players. These feelings antagonized the entire team and
was the root cause of the paralysis. I reformulated the
project into a series of subprojects that allowed the hostile
parties to work separately. This got the project back in
motion, and we were able to complete the project in its one
year life cycle. Managed 12 professionals.
P.S. -- those two players never became friends and took separate
career paths.
discovered strong animosity between two very strong
players. These feelings antagonized the entire team and
was the root cause of the paralysis. I reformulated the
project into a series of subprojects that allowed the hostile
parties to work separately. This got the project back in
motion, and we were able to complete the project in its one
year life cycle. Managed 12 professionals.
P.S. -- those two players never became friends and took separate
career paths.
| Major bank |
| Financial Services software development |
- Don't develop a project plan backwards (from delivery date to
implementation tasks). - Don't shorten or omit task steps to reach a delivery date.
- Start by treating the time durations as part of a respectable work
day, not starting in crisis mode. (Invariably, the crisis mode may
take hold but that should be later in the project as an
accelerant, not as the project-approved norm). - Prepare documentation for different levels of readers -- senior
managers, line managers, business stakeholders, interfacing groups,
developers, testers, help desk, trainers, users. - Don't fall victim to 'canned' project plans. Some engagement
organizations are famous for recycling their one-size-fits-all
boilerplate documentation. You get a lot of shelfware for your
money but no useful documentation.
- Read the project plan as a road map, not divine word. If some
dependency is stopping you, work around it or start some later part
of the plan that is not dependent of that stoppage. - Don't compromise time -- if testing is going to take ten work days,
testing for only two days doesn't do the task justice and can't possibly
result is a good product. - If you want to make up lost time, consider parallel tasking of
independent task streams. - You can't make up lost time by putting more people on the job or
by putting the team into crisis mode. - Be very active in the task steps, not just a weekly status checker. If
something is going awry on Tuesday, don't wait to learn of it on
Friday.
- It has its place in the Project Life Cycle.
- The better defined the project task steps, the more accurate the MS
Project plan result. - It is not a good tool for visualization when parallel tasking is
prevalent. - Most Gantt charts are a waste of printer paper (I see them all the
time laying in the printer out-tray). You are better off with the Task
Sheet view. The only time I found a Gantt chart useful was in a data
center build-out for an investment bank. We had a plotter that
generated a six-foot long Gantt that was pinned to the wall for all
PM's to read (in fear, I might add). - MS Project drives me crazy when I change the resources on a task
and the absolute time is halved or doubled.
|
|
|