Skip to main content

Project Plans Require Nurturing Leadership

I was recently chatting with a colleague who was complaining about project team members ignoring his directions, neglecting a schedule he’d built before a short vacation and consequently getting an email from his unhappy client about project delays. I asked if he’d held a meeting to discuss assignments and appoint someone in charge. When he frowned and shook his head “no” I knew nothing more need be said. He realized his mistake was to assume everyone would read the plan and stick to it. Project managers can’t build a project plan and just assume everyone will follow directions.
 
I’ve stated more times than memory serves that project plans are living entities, changing and adapting as time passes, requiring constant attention and attentive care to flourish. A project manager must be a project planning and plan creation specialist, and they must be effective in human interaction, motivation, guidance, and cheerleading. He or she needs to play all roles simultaneously, immersed and conversant in every detail, the glue that keeps all parts in place and the oil that keeps everything working smoothly.

Speaking From Experience 

I was introduced to project planning and management very early in my career, before automated project planning tools existed, when project plans were written on coding sheets. I started out as a secretary, transcribing rather than constructing, gathering project participants’ updates, then updating the tasks with progress, completion dates or issues. We held weekly review meetings to validate changes—generating more updates. The knowledge I gained about project management during this time served me well during subsequent engagements.
 
My biggest and most challenging project was conversion of a large claims processing system from IMS/DB and IMS/DC to CICS Transaction Server and IBM Db2, including elimination or standardization of application code built on a defunct vendor product. One client staff member had working knowledge of this vendor code, and we had a few outdated manuals, but mostly it was tedious observation of how vendor software worked based on testing the existing system.
 
This wasn’t a practical way of gaining insights on what it would take to perform the conversion, so I proposed a small contract to assess project scope and challenges posed, producing a written summary and a high-level project plan as the contract deliverable. They considered this reasonable, and it paved the way to a long-term engagement and detailed, extensive project plan I’d have to manage. I estimated the project at 10,000 hours worked between myself, three staff members, two subcontractors and two client members.
 
All project participants’ technical skills were excellent and disparate to match project makeup, and at first it was like trying to herd cats as each pursued their own tasks and research, intent on individual project assignments. A few technicians were very strong-willed and obsessed with their tasks, and one ignored our client’s requests for findings, status updates and task prioritization. They clashed in a status meeting, where a frustrated client confronted the consultant with heated words. I realized I had to take a stronger, more involved role; weekly status meetings and ad-hoc telephone calls were insufficient.
 
I dove headfirst into every project facet, starting with the recalcitrant staffer, pointing out he wouldn’t have a job if I didn’t have a contract. Secondly, I set up conference calls and established myself as the mediator on these calls. I contacted every team member and client daily, because many worked from home, so I had to establish a setting where everyone worked as if in a single room. I became a clearing house, babysitter, guiding force and jack-of-all-trades. I had to unify and motivate the team. Most of all I had to lead, not just manage.
 
Although my technical skills were more varied than others, leadership was more important to project success, because the group became a team working together and sharing ideas. A good plan wasn’t enough, and individualized albeit concerted efforts couldn’t achieve success. I took charge, and while I was initially unsure, I noticed improved attitudes almost immediately as I paid more attention to every project step. Cooperation increased as member communication improved, the pace quickened and members began working together.

Don't Just Assume 

Project plans—no matter how comprehensive, well crafted or clearly constructed—don’t guarantee success. They’re only an organizing tool; it’s the project staff that make it work. Just as sports teams need a coach to define strategy, assign roles, explain responsibilities, see necessary assignments are done and inspire participants, project staff members need a leader who takes on these responsibilities. Assuming a project plan alone can achieve this is sheer folly. A good project manager doesn’t just assume things will work out. They find a way make it happen.

The Project Leader Should Know the Plan 

Ideally, the project leader creates and maintains the project plan, and in many projects I’ve run, that’s how it worked. One advantage of this practice was that I knew the plan inside out and often could recite many task details from memory. This approach depends on project size. In the case of large project plans, it’s often necessary to assign the project secretary to handle tasks and related details during plan construction, and changes involved in keeping the project plan current.

Technical Skills and Knowledge Is an Immense Asset 

My first client after joining IBM demanded I do more than just consult; they expected me to get my hands dirty in their system’s application programming and system programming processes, and the skills I learned gave me an edge on other consultants for years to come. I could speak project participant’s language, understand their issues, and that gave me credibility that produced respect no outsider could claim. I was one of them, a peer, even though I worked for a different company. We shared skills, acquaintances and experiences. These kinds of technical skills are an asset for any project manager.

People Skills Are Key 

My experience is with technical projects, but a common thread to all projects is they’ve all been managed, and they’ve all been accomplished by people. As a result, the need for interpersonal expertise is universal. People skills are especially important to projects because numerous individuals with differing abilities, opinions, commitment, motivation and determination must be unified to a single purpose, to work together, constructively share ideas, and help each other attain objectives outside of their own.
 
A project manager must understand human nature to arbitrate negotiations, to catalyze and nurture creative solutions of intractable problems, and to take different personality types with varied skills and mindsets. This quality will help project managers turn project employees into a team willing to share and concede to others’ will and greater knowledge, to put aside differences and pursue a common solution and outcome. A project manager needs to lead, set expectations, sell ideas, understand when to reward and when to chastise, and know when to use informal authority when formal authority fails.

Intangibles Make All the Difference 

After the clash between my engineer and client, I began calling my consultants and clients daily to discuss the three P’s: progress, problems and personalities. I took action on information garnered from calls, arranging meetings between members that needed to talk, driving problems, scheduling twice-weekly conference calls, changing priorities as needed, sometimes serving as arbiter, facilitator, director or troubleshooter.
 
Everything changed. Doing work charted by a thoroughly researched, carefully crafted project plan, signed off by everyone, working within prescribed time according to negotiated specifications, only happens when the project team works like a well oiled and tuned machine. Project success  requires effective leadership. I immensely enjoyed my technical work, but it was my pervasive presence in every project nook and cranny, and my role as a jack-of-all-trades that enabled my associates the freedom to successfully perform and create.