Mark Gibson; PgMP, PMP, IBM certified Executive Project Manager

How to remain Objective?

In reading LinkedIn, I came across an excellent article on Inc.com magazine written by Kevin Daum and wanted to share the hightlights and add an additional thought.

His article defines 5 things that really smart people do.  In reading the article, they seemed to like good techniques to ensure a project manager remained objective in their thinking.  As the leader of a team, I have written about the need to engage the project team and leverage the expertise, experience, and ingenuity of all project team members.  The article defines the following:

• Quiet your inner voice - the voice that talks to you, distracts you, and keeps the project manager rooted in their own ideas.
• Argue with yourself - if the inner voices insists on being heard.  Challenge the notions.
• Act like you are curious - define additional or ancillary topics to research
• Find the Kernel of Truth - identify the facts behind the assertions.
• Focus on the Message and not the Messenger - personal relationships can impede our openess to other ideas.

I would add one additional one to the list.  Attempt to understand why someone has a belief, taken a position or is proposing an idea.  This is not to identify some conspiracy but to recognize a contribution and get back to the basis for the conclusions or base level truths.  These base level truths are typically used as a basis for generating an idea and central to acceptance of the conclusion by the orignator and the people to whom the idea is proposed.  Once agreement on these base level truths is attained and agreed upon, the construction of the exact idea on top is an easier endeavor and gaining agreement is easier.

Objectivity is important for a project manager as they not only manage technology but also people.  The managing of the people is an important part of achieving success.  Being open to the ideas of others increases the chances of success by considering more ideas and motivating the project team to be innovative and being a vital part of the project's success.

Requirements: Are they a necessary part of a software project?

Historically, we have taken the approach of developing requirements through many different mechanisms.  We may ask the customer for an initial set.  We may conduct Joint Application Design (JAD) sessions where we conduct meetings for multiple days to extract requirements from our customers.  These techniques and many others remain a central part of many software development and implementation projects today.  Are these techniques still central to the process?

In the late 80's and early 90's, we began to see an interesting dynamic occuring.  When asking our customers for their requirements, a couple of results were commonly seen:

• The customers knew how their current system worked but had difficulty articulating what the requirements were and in particular identifying all the requirements.  Articulating all the system features was not something they thought about or did everyday so asking them was/is a very difficult task.
• The customers also tended to describe their current system and what it did as opposed to what the business needed the system to do.  Customers know their current system so a natural place to start was articulating how they used their current system, a logical conclusion but one that tended to design the solution including potentially unnecessary customizations in commercial software.

The common end result of these sessions was a set of features that did not meet what the customer needed and in many cases were just a subset of what the system needed to do.  Lay on top the duration of the activity and length of time to develop resulted in requirements changes and utlimately a dissatisfied customer as the solution did not meet the business needs at the time of production deployment.  The end result was projects going overtime and budget due to scope creep from the project team's perspective but necessary features from the business perspective.  Both positions were fair and justified.

As these dynamics became apparent, we began to develop several tenants that remain true today.

• Customers have a greater capability to describe what is needed when looking at a prototype of the solution or at least business processes.  Business Processing Re-engineering (BPR) has been around a long time and is not as prevalent as it used to be.
• Customers have a greater capability describing what they do on a daily basis and even infrequently.
• Working or partially working software is a better tool for understanding what a solution needs to do than any form of documentation.

This has lead us down a path where use cases and/or user stories have become a legitimate mechanism for defining what a system must do.  The prototyping techniques and now the agile methodologies all expouse this mechanism as a favored way to define the scope of a project.  Combine this with business processing modeling and the project manager has a different tool to define the "What" of the system.  Process modeling and use cases also provide four additional benefits:

• Is more systematic as the team's tend to look at all paths and not just the happy path.  In a process model, a decision point must have a Yes and No path to the question.  In many questions, one or the other is an edge case so can be overlooked when reviewing just use cases. Modeling has an inherent auditing capability that tends to drive more thoroughness.
• Provides a mechanism to look for process improvements.  In many cases and once the process is defined, customers can more easily identify steps or decision points that are no longer needed or can be streamlined.
• Is agnostic of the legacy application which enables the project team to define a design or configuration for commercial software unburdened by the legacy system.  For commercial software, this is particularly useful in working within a core product and avoiding costly customizations.
• Provides a better mechanism for the test teams to become involved earlier in the project.  When developing requirements, many test teams opt to review the session output and do not contribute to the requirements development.  By using modeling and use cases when the use cases drive the structure and scope of the testing, the testing teams are motivated to participate early.  The test team also provide a valuable service as they tend to be very systematic in thinking through edge cases and error scenarios resulting in a more complete set of use cases or process flows.

In summary, defining "what" the system needs to do remains a critical part of a project.  As we have evolved, how we define "what" has more options that now include business process modeling, use case or user story definitions, and prototypes as a substitute for requirements gathering.  When beginning a project, considering the appropriate mechanism for defining scope is an early and critical project management decision.

These mechanisms have different advantages depending on whether the project is a consulting project with a scope based statement of work whether it be a custom development or commercial software implementation or a product development organization developing and improving a commercial product for sale.    These pros and cons of these techniques with respect to the project type are a topic for a future post.

Personality Traits of Successful Program and Project Managers

We have all observed program and project managers who are successful.  They make it look so easy and to many it is easy, as they possess certain personality traits and skills that acclimate them well to the profession. But what are those traits and skills; and how do we identify them in our employees or candidates so we can build a strong program and project management team within our company.

Many others have written on the subject so below are excerpts that begin the list.  This list also includes what I would call skills of project managers and typical tasks that makes program and project managers successful.

CIO Magazine	Williams Company	the99percent.com	Recruiter.com	Project Times
They possess the gift of foresight	Be completely obsessed with the Client.	Command authority naturally.	Clear Vision	Be an extrovert
They're organized.	Provide crystal clear project goals and be accountable.	Possess quick sifting abilities, knowing what to note and what to ignore.	The Ability to Delegate	Display personal courage (lead from the front)
They know how to lead.	Communicate clearly and effectively in all directions.	Set, observe, and re-evaluate project priorities frequently.	Communication Skills	Possess charisma
They're good communicators	Define roles and responsibilities of all team members.	Ask good questions and listen to stakeholders.	Problem Solving Skills	Be an enabler with a can do attitude
They're pragmatic	Create a viable schedule with total team commitment.	Do not use information as a weapon or a means of control.	Leadership Competence	Have a strong sense of teamwork
They're empathetic.	Identify the big risk items and mitigate them early.	Adhere to predictable communication schedules,
	Prioritize ruthlessly.	Possess domain expertise in project management as applied to a particular field.
	Anticipate and accommodate change.	Exercise independent and fair consensus-building skills when conflict arises
	Challenge assumptions and self-imposed limitations.	Cultivate and rely on extensive informal networks inside and outside the firm to solve problems that arise.
	Manage the client’s expectations.	Look forward to going to work!
	Learn from experience and mistakes.
	Have an attitude of gratitude and thank those who helped you succeed.

Many themes jump off the above lists including:

Leadership

Leadership is identified separately from management, as leadership is more of a personality trait whereas management is a learned skill.  I recognize this is not a common view as many people and companies espouse courses in teaching leadership.  Here, I am identifying people who can motivate others as projects are long endeavors, which invariably have points where the success of the project falls to the project manager who can keep the team motivated and get them past the sticky problems observed on nearly every project.

PMs also have to instill confidence in both their teams and the manager(s) to whom they report.  As stated before, projects are long and difficult endeavors, which have plenty of challenges.  When these challenges arise, PMs who are able to maintain the confidence of all interested parties have more success.  When the confidence in the PM is shaken, executives tend to provide additional assistance to the teams that is a sure sign of lost confidence and adds additional effort to the project. The group of engineers will operate indepdently producing a fragmented solution.

People in general bring a set of implicit assumptions.  These assumptions are not typically in the forefront of their minds but exist due to their life experiences both personally and professionally.  These assumptions then drive the set of solutions they are able to envision.  When a PM is able to identify these implicit assumptions, validate their relevancy to the unique project, then challenge them if need be, better solutions to problems are identified.  These better solutions may be quicker and less risky to implement, require fewer resources or less highly skilled resources, or have a better impact on the business.

Management Skills

On all projects, there is a finite amount of administration that occurs and this to me is the management of the project.  The management component of project or program management requires multiple skills as well as traits.  The traits include the ability to organize.  Projects inherently have lots of moving parts from end users and sponsors with thoughts, to technicians who have commercial applications to configure or code to write, to test teams and configuration managers who have plans and backend support systems to bring on line.  All of these disparate groups must be brought together and coordinated so the project can move forward and eventually complete.  The ability to organize the multiple teams is a personality trait inherent is successful program and project managers.

We also have to organize at a deeper level when dealing with the technology.  The task of building a Work Breakdown Structure (WBS) is a feat in organization when done well.  Not only do business and technical executives have to understand both the strategy and tasking but also the technicians who will perform the work.  Laying out a structure that is understood by both disparate sets of people is difficult at best.  Now include the capability to track progress in a meaningful way for both groups and the need for deep organizing trait is paramount. 

Closely related is the ability to plan, to foresee how a project will come together.  Planning also includes what deliverables are needed, how and when to develop test plans, how many test plans are needed, what metrics are needed, and which resources execute which tasks in conjunction with each other.  All of these are unique to each situation as the Statement of Work (SOW) or Project Charter is unique as well as the scope undertaken and the resources assigned to the project.

The ability to manage both your own time and the time of those working for you is critical.  Projects have so many distractions making it very easy to head down a rabbit hole that derails the project.  These typically happen during the development phases but can also occur at any phase.  Contrary to popular belief, the highest risk time of a project is the beginning and not the end.  Many times I use an analogy of catching a wave for a surfer.  This is analogous to setting the scope and planning phases of a project.  Once you catch the wave, the time to the beach is out of your hands as the wave is going at its own speed.  You can make some moves that will have some impact on the timing but the base timing is already defined.  Successful project managers take their time in planning and resist the temptation to get starting developing because time is short.  Each project has numerous options on how to approach the work. It is this approach which is analgous to catching the right wave, that has the most dramatic impact on project timing and success.

Setting the priorities for individuals and managing to those priorities becomes a main activity during the majority of the project.  This requires the PM to handle multiple tasks at the same time.  The moment the first task is delegated, the PM is multi-tasking.  If an individual tries to handle all tasks themselves, a project of any size is at risk.  On a typical commercial software implementation, I will have the following threads open: 1) software configuration, 2) interface development, 3) conversion or data migration development, 4) custom software development, 5) communication with sponsors, 6) communications with consulting company management and sales, 7) project tracking and monitoring, and 8) potentially open core product issues or enhancement.  The ability to manage your time, multi-task, and manage the team's time is a critical skill.

All projects include the use of teams.  These teams include resources for which the PM has direct responsibility and other resources for which the PM does not have responsibility.  All of these teams must come together and work toward the common goal of completing the project.  The team will consist of not only these individuals but also the managers of the matrixed resources as they potentially have competing goals.  The ability to create and motivate teams becomes a determining factor in the success of PMs.

Communication Skills

The ability to communicate in both written and verbal form both up and down the management chain is a widely known required skill.  In the previous paragraphs and going forward the implication of communication skills jumps off the page.  Let me delve into a couple of areas that are not as widely held.  The first is with whom PMs communicate.  I have mentioned the need to discuss topics with business and technical leaders as well as the technicians but what is also needed is the ability to define or clarify technical or business problems to the opposite group.  Many times on a project I will come across a particularly difficult technical issue that either impacts the dates or is a risk to those dates.  Naturally, both the technical and business leaders want to understand the problem.  Given it is a technical issue in this case, discussing technical issues with technical people is easier than helping a business leader understand why the web application crashes because of Java Virtual Machine (JVM) Heap is exhausted and why this is a problem given the CFO just spend dollars increasing the memory on the application server.  These are important topics for them to understand as well as the opposite.  Helping the technicians understand why a good technical solution has dire consequences for the business side of the house.

PMs are also knowledge conduits.  They should ensure that information from one team gets to all the other teams that need it.  As project schedules get tight and the tension begins to increase, many people naturally focus on their tasks at hand to become more efficient and get their work done.  A great thing for that individual task but what happens when the other teams need information from this one group and cannot get it.  The other tasks naturally fall behind so the project falls behind.  The PM that stays in touch with what all groups are going and moves the information between groups can more effectively keep all tasks moving and avoids disconnects when the “right” hand is not talking to the “left” hand.

Foresight and Vision

Some people have the innate ability to see the future.  I am not talking about crystal balls or palm readers but a sense for the direction the project is headed and the ability to see risks and envision how all the elements of a project will come together in the end.  I alluded to this concept in the planning section and it applies here as well.  In conjunction with planning is the skill of defining goals for individuals that are in sync with the plan.  In my post, “Staying on Schedule”, I spoke about intermediate milestones and mini-crisis as a mechanism for maintaining a schedule.  The ability to foresee, define, and articulate these goals goes a long way toward staying on schedule and being successful.

Risk management is a key aspect of successful projects and is in many instances not well received as an integral part of a project.  In many organizations and as an attempt to manage time, organizations only deal with issues and not risks.  Many times, I have highlighted risks to be told we will deal with it when it becomes a problem.  The personality trait to envision a risk and the capability to address the risk are key elements to success.

Pragmatic

As PMs we are constantly in the situation of making choices.  Usually all day is spent making trade off choices between competing forces.  There are times when we have to make a choice a deliverable is good enough, not perfect but good enough as it meets the business objectives.  The prime example comes when dealing with the speed at which application pages are rendered.  I routinely hear from end users and sponsors that I want the page to be as fast as possible.  From a conceptual standpoint, this makes sense as speed of page rendering translates into efficiency of workers and eventually money.  Fast as possible does not mean get 6 Cray super computers for my solution or that I want sub second response time on a page that is making two web service calls and returning a three table join query.  Clearly, neither is going to happen.  What was meant was to increase the speed until it reaches a good balance between cost, time and speed.  This is not a straightforward decision.  The technician would ask for the performance requirements so they know the solution to build; the businessperson wants a reasonable cost so the PM is in the position to determine what is good enough.  The balance point falls to the PM and pragmatism is key.

Conflict is also a common occurrence on projects.  It can be between two technicians, the test team, developers, the business people, etc.  The ability to work through issues and even decide on what issues to engage is something critical to success.  People can be passionate about what they believe in so getting past these points of contention whether it be negotiating a resolution, facilitating the discussion or deciding which battles to fight becomes important to success.

Can do attitude 

In our world, there are people whose glass is half full and those whose glass is half empty.  The perspective on adversity, challenges, and dealing with people go a long way toward success in a work environment that typically includes strict deadlines, changing requirements, heavy budget pressure and big business impacts when the project does not go well.  A can do and positive attitude is a personality trait that serves PMs well dealing with adversity, the high-pressure situations, team building, and leadership.  Finding this personality trait in a person serves them well in the profession of Program and Project Management.

In addition to the above list of skills and traits, I would add a personality trait of cool and thoughtful under pressure.  Projects are intense, long, and difficult activities that have periods of time when the PM is under significant pressure due to impending deadlines, difficult issues, etc.  People are also very passionate and so the PM is typically under a lot of pressure and must be able to think on their feet and remain thoughtful during the intense times.  It is these times when PM can easily lose the confidence of management or their teams, lose control of scope, or any number of other occurrences that negatively impact the project. 

There are three inputs in the table above I would not agree with:

1. Be completely obsessed with the Client.

Client focus to a degree is a very good thing.  In situations where the project manager is also managing a team and a contract then a proper balance between these many times competing agendas enables the project manager to not only meet the client goals but also individual and company goals.  In these situations, the project manager has multiple people and organizations to which they report and must meet the goals of each individual and organization simultaneously to be successful.

    2. Be an extrovert

Due to the need for extensive interaction with people, extroverts typically have these skills inherently.  Individuals who straddle the introvert/extrovert category can also be successful as they can communicate and operate in the people centric situations.  Strict introverts who prefer to work alone and on individual tasks will struggle in the PM role.

    3. Display personal courage (lead from the front)

In my previous post, I discuss the relative timing of leading from the front and back.  Different situations dictate assuming each style so both are needed and not just leading from the front.

The personality traits and skills needed for project managers to be successful are varied.  When interviewing PM candidates and identifying internal candidates for a PM role, these people centric traits and skills are far more influential in the success of PMs.  What may be interesting to many people is the lack of technical expertise as a main contributor to success.  Certainly, technical and business expertises are needed for a project to be successful but are typically skills for others on the project.  With the exception of enough domain knowledge to understand the business goals and to speak intelligently to business leaders, the other traits and skills are much greater contributors to the success of a Program or Project Manager.

 

 

9 Beliefs of Remarkably Successful People

This article by Jeff Hayden and published in Inc Magazine was so engaging and spot on I had to publish.

Status Meetings: Necessary or a distraction?

Status meetings are a common occurrence on many projects. Project teams get together and project managers solicit the status of individual tasks from team members to update project plans or maybe understand the tasks individual resources are working on. These are certainly necessary activities but is a meeting the appropriate forum for soliciting this information.

Project team members and especially the more senior staff are typically strapped with a large volume of work and required to produce in a short period of time. Meetings in all forms take these especially as well as all team members away from focusing on their work. Some meetings are needed as these same members need to coordinate or make decisions with other team members or members of the customer staff. This problem is more acute when team members are heads down on difficult tasks or troubleshooting problems when uninterrupted focus is helpful to finding answers.

If not in a meeting, then how do project managers get the information needed to properly manage the project? In my projects, I ask the team members to carbon copy me on email traffic going back and forth between the project team and the customer. By monitoring this traffic, the project manager can understand the status without interrupting the resource's work or focus. When traveling, additional opportunities are available when eating meals. The project manager needs to know the staff as some individuals like a break during meals so sensitivity to the individual's needs must be acknowledged. There will be times when direct interaction on status is the only mechanism. By using these avenues to gain status, the project manager can minimize the amount of time spent getting status enabling the resources more time to focus on their work.

What should be the agenda of periodic meetings with the project team?

 In my meetings, I focus on three things: 1) the needs of the people on the team, 2) what I am working on to assist their efforts, 3) outside influences on the project whether those be within the customer or company in which we all work.  The needs of the people can be anything from technical issues on which they are working, access issues to for example a source control tool or test executive.  They can be personal needs such as personal time off or needs to coordinate with other team members or customers.  This aspect focuses on the team members and what they need to be successful and efficient.  If there are ways that I can help, then those actions are taken.

One of my primary focus areas is risk identification and management.  This is my opportunity to brief the team on my contributions as well as where their assistance is needed such as in project planning or the program management plan.  The risks I have identified are documented, understood by all parties and the progress briefed to the team.

Outside influences can hinder a project as we all know.  Understanding these influences and working to mitigate the effects is something project managers can spend more time doing.  These influences can be related to company policies, issues with housing arrangements for team members visiting from overseas, etc.  By spending time in these areas, the project manager can demonstrate they understand the day to day challenges, care about the lives of their people, and work towards making better work places.  What the project manager gets in return is a happier and most efficient work force which leads to higher levels of productivity and predictability.

Finally, I open the floor to any topic that any team member wishes to discuss so this is not my meeting but the team's meeting.  Typically, the topics are coordination between team members, when to work together on technical issues, more junior members asking for advise or discussing ideas on a task or issue.  I have faciliated discussions about hotel arrangements, personality issues between team members and customers.  A wide variety of topics are discussed and can be.

I know the question is coming so these meetings typically take less than 15 minutes when hosted twice a week.  On rare occassions they go longer but that is typically because the team members are having longer discussions on a topic.  Keep the meetings short!

In conclusion, status meetings for the collecting status are a distraction.  PMs should find other ways to collect status information so the team members can remain focused on the tasks at hand.  Keep the meetings short and focus on the needs of the team members.

Does Project Planning consist of a project plan?

In nearly all projects these days, project managers produce a project plan consisting of the work breakdown structure, resourcing, etc. Does the process begin and end with this plan? Many people would say the plan is the beginning and as events unfold this plan is updated with status, revised to address issues that arise, and ultimately completed. I would agree with this notion but suggest the project plan is not the first planning deliverable. It needs input not only for the work breakdown structure but also from other sources. These sources include those management processes that underly all of our projects.

In my projects, I produce a deliverable originally called a Project Infrastructure Document from my days at PeopleSoft to now a Program Management Plan. Each term is a good description as the infrastructure of say a house begins with the foundation. The same applies to projects or programs. So what are the foundation management processes and policies underpinning all projects? They include at a minimum:

• Communications Plan – defines the type, format and timing of all internal and external information dissemination about the program.

• Quality Assurance Plan – defines the use and timing of any quality assurance functions that can include, but may not be limited to, design and code reviews, milestone reviews, and metrics.

• Risk Management Plan – identifies any risks to technical or business goals, identifies the impact of the risk, likelihood of occurrence, and documents mitigation plans.

• Education Strategy and Plan – defines the manner and mechanisms by which individuals such as the technical staff and customer support staff will gain the necessary knowledge to effectively operate and sustain the developed solution.

• Testing Strategy – defines the types of testing required during the development, goals of each test phase, defines the drafting process for the test plans, and the process and tools required for testing.

• Configuration Management Plan - The configuration management plan defines those set of procedures to ensure that both the solution code and master data are maintained in a controlled fashion.

• Rollout Strategy/RoadMap– defines the relative timing and functionality deployed to production.

• Project Plan – baselined after completion of the first seven chapters, it pulls all aspects of the development into a consolidated execution plan. The project manager will update this plan periodically as solution requirements are finalized.

In addition to the chapters above, I have on occasion included project acceptance criteria, travel policies, and budget baselines when unique project conditions warrant a more formal documentation of these policies. By formalizing these processes and policies within an early deliverable, I am able to better assess and estimate the duration of activities which drive the schedule. For example, by understanding all the test phases, their objectives and who will execute the tests, the durations of each individual phase is better understood as well as the level of effort for my team. Imagine a circumstance when the PM is expecting a testing program that includes unit testing, system testing, and then a production decision but the customer is expecting a performance test phase and a user acceptance test phase in addition to the above. Including these additional test phases establishes a very different testing program and the associated schedule.

At a deeper level, consider differences in expectations around the objectives of each phase. I have experienced a customer that defined unit testing as the validation of the proper interaction of all solution components including interfaces, conversions, and use cases and with production like data. This definition is very different than most of us would expect and creates a different set of activities, staffing, and durations. Or consider a project where the testing phases require all severity level 1 and 2 bugs be closed before proceeding to the next test phase. These are very typical criteria with typical defintions of the levels but what happens if the definition of a severity level 2 includes functionality with workarounds, the dynamic changes.

The project plan itself is included in the document as with many contracts, the project manager may want to formalize the initial plan as the baseline upon which statements of work and budgets are committed. Project plans by nature are living documents while contracts and budgets are not, so having a more formal baseline or starting project plan can prove valuable when schedules begin to move to the right and either financial or legal professionals begin to ask for the circumstances behind this schedule movement.

Based on our experiences, we each bring assumptions to the processes defined in each of the chapters above. Some of these assumptions are identified in the paragraphs above as well as other conflicting assumptions which I have personally experienced. Highlighting those assumptions in written form brings them to the forefront and enables discussions at the outset of the project. Differences in these assumptions can be discussed and reconciled long before they have a negative impact to the project or cause anxiety between counterparts.

The program management plan has enabled me to remove or minimize risks of these circumstances occurring. The biggest challenge is taking the time early in the project to discuss and reconcile the details of these processes vice waiting until issues or misunderstandings occur.

Leadership under Stress

In my recent post Lead from the front or back, the topic of leading from the front or back was discussed. Although leading from the back is the preferred approach in most instances, times do occur when the project manager is needed at the front. These times include the days just prior to going live, when schedules are not being met, or even when technicians are struggling with a task. So what is different about leading from the front? I think there are four differences when leading from the front and especially in high stress situations.

Increase communication and coordination

The tendency of people when operating is high stress situations are two-fold: 1) they focus exclusively on the task at hand. This is a good thing if the resource is a technician and needs to complete a critical task, but can cause disruption if someone is not coordinating the activities. 2) they become overwhelmed with all the activities and bounce between different activities and are unable to complete any of them.

When these situations arise, they are characterized by a large number of activities that need to occur in tight succession across many different teams and within a very tight timetable. The few days before going live are a typical example when conversions are running and one needs to start immediately after a previous conversion has concluded, additional setup needs to occur, network connection verification is occurring at the same time, then security verification, final builds and final testing prior to turning on the switch. The amount of activity requires both an increased level of coordination as well as communication and is perfectly suited for the project manager to step into this role.

By increasing the coordination and specifically this does NOT mean more meetings but managing by walking around. The project manager should get on the phone or walk to the desk of the people who are executing the tasks and minimize the use of email, texts and all non face to face communication. These other mechanisms are slower when speed is of the essence. By seeing the resources face to face, the project manager can also gauge when resources are becoming overwhelmed with all the activity and provides an opportunity to both brief the resources on the progress and encourage them.

Finally, the project manager should find a mechanism to keep senior management informed of the progress. I will typically do this in two ways: 1) provide a summary level status on something like a spreadsheet, wiki, or project website so the executives can look for and review status when time allows, 2) spend 5 minutes each day to brief at least the sponsors on the progress. This briefing will include the tasks completed, a summary of on schedule status, any challenges, and what activities are next.

Define discreet objectives

The activities given to technicians at this point should be very discreet and well defined. In the non-stressful situations when leading from the back, providing technicians more general guidance provided them a way to be creative and use their problem solving skills. When in stressful situations, this can work against the project manager as that creativity may not sync up with the creativity of other technicians.

In these instances, a very defined tasks such as open port 8081 on the web servers, execute the conversion script for loading customers, or update the application server with code base 1.2.2. This level of tasking ensures the synchronization of all resources and minimizes the chances of activities getting out of sync. In most cases, such as going live, the activities were defined in detail previously and the technicians played the most significant role in defining the activities. When the stressful time begins is when the project manager can take over and lead from the front. 

Take care of technicians first

In these situations when a large number of activities are occurring either in succession or simultaneously, there is a natural conflict in managing the project manager's time executing their assigned activities and managing the activities of the project team resources. Time becomes short and there are times when the project manager needs to chose between executing their tasks and supporting the technicians. In these instances, I always support the technicians. Why is a question that may come to mind?

The most important people in getting a new solution live or in stressful situations are the project team members! The project manager can help with planning, coordination and many other tasks but the technicians and functional business resources are the ones that make it happen. In the case of going live, the planning is done and the team is executing at that point and the people who execute the plans are the technicians and functional business users.

In these situations, the project team will be stressed out. They are being pushed from all directions. When situations occur where the project manager is pushing the resource and the resource needs help, the project manager needs to help them first. Let's look at the opposite situation... The PM is pushing the technician to finish a critical task, the technician needs help but the PM goes off to update a status report or some other task on the plate of the PM. How does the PM look in that situation? The PM is pushing but won't help when it is needed. The PM loses credibility with the technician.... the urgency is no longer there... Not a good situation. Even when the PM task is to brief an executive, the PM should help the technician after calling the executive and explaining of course. In my experience, I have seen very few executives who do not want to see the work completed first before they are briefed and especially in high stress situations.

Eliminate distractions

Distractions are a constant sources of schedule delays and a non-productive consumer of capacity. The level and number of distractions can increase dramatically in high stress situations as some resources become overwhelmed with the situation, become uncomfortable with a previously agreed upon plan, or even begin to consume other resources.

In the case of going live, the easiest way to eliminate distractions is to develop a go-live plan before the actual date of going live. I routinely execute dry runs of the plan to both identify errors and create an increased comfort level. In situations where schedules have been breached, this option is not always available so communicating and coordinating with also help to minimize the distractions.

When the time does come when the project manager must lead from the front, the concepts above will assist each of us in working through that high stress situation.

Lead from the front or the back

Earlier this week, I was watching the movie "Gladiator" for the nth time and how the Russell Crowe character lead his troops into the battle with Germania. He developed the strategy with his lieutenants, determined the points when new phases of the battle should begin such as when to unleash "Hell" and when the cavalry would engage which is personally lead. During the cavalry sequence, he lead from the front and was the person who made initial contact. The same is true of Mel Gibson in "BraveHeart" where he lead the infantry charge from the front. This started me thinking about leading from the front and back during software projects. Is it appropriate for a program and or project manager to lead from either the front or back and if so when.

In thinking about what I have done, sometimes I lead from the front but mostly the back. There are several circumstances that move me to the front and in this case leading from the front means rolling up my sleeves and doing the implementation or development work. This could be writing use/test cases during the initial stages of the project, working with business leaders to understand the business requirements or problems the program or project is intended to solve, understanding operational issues that have come to light, assisting with a particularly sticky technical problem.

In cases like working with the business leaders early in the project or analyzing operational issues, these seem to be mainstream activities for a program manager.  The liaison with the business frees up the technical staff to work through the solution itself as well as build and test it. Defining and breaking down business processes into use cases and test scenarios/cases also seems like an important activity to lead from the front but this is also when the PgM/PM begins to move to the back.

In my post "Project Management through Lists", I spoke about maintaining a strategic view of the program/project and this is where leading from the back begins to come into play. For the use/test cases, it is important to ensure all business processes are identified which is more difficult to do when technicians are looking at all the detailed paths. The same concept applies when looking at a balance between different business requirements. A follow-on project may be defined to decrease the time to market for a software application serving customer service representatives. Time to market is the parameter the project is intended to improve but if the solution also decreases performance, scalability, and maintainability, will it be accepted or deemed appropriate over the long term. Probably not, so leading from the back and keeping a strategic view of the solution is also an important activity.

The side effects of leading from the back enable us to look at the pace of multiple parameters important to the concepts of project success and staying on schedule including:

• burn rate of budget
• pace of development across the multiple parallel threads such as interfaces, conversions, code development
• pace of knowledge transfer to operating organization
• mix of staff across labor categories
• assignment of staff across technical activities and potentially moving resources.  This is where "Utility infielders on Projects" comes into play.
• mechanisms to achieve business requirements

There are times when leading from the front is needed such as when engaging with the business or when activities are not going well. For the most part, leading from the back seems the most appropriate place as it also frees the technicians to be creative and implement their ideas on the solution which ultimately makes them happier and more productive. Clearly, the Program Manager who is leading multiple teams and will spend a majority of their time with the business is going to lead almost exclusively from the back. Ultimately, this is the best place from which to understand and manage the fundamental measures of project success.

Project Management through lists.

Can a project manager be successful by focusing on and managing through lists?  

The answer to this question has a couple of aspects depending on the purpose of the list.  

Many implementation methodologies contain checklists for the purposes of project planning, project monitoring, technical or functional reviews or test phase preparation as examples.  These lists serve a valuable purpose of reminding the technician or project manager to consider an exhaustive list of concepts or ideas when executing a specific task common in many projects.  These items for consideration were typically born from best practices and lessons learned over many previous projects. These lists of reminders are valuable as they remind the individual of details that may othewise be overlooked and should have a place within any project.

Many project managers also use action item lists or lists of issues to which I referred in Issue Lists: Are they a good thing? and I defined some of the pitfalls with using lists for technical issues.  Clearly, driving issues to closure is part of what a good project manager includes in their day to day activities but this is only a part of the overall tasking.

PMs who focus exclusively or even mostly on working lists of issues do not always place enough emphasis of  what I would consider even more important elements to managing the project.  These include but are not limited to:

• Physical and mental state of the project team members
• Confidence of the stakeholders in the project progress and documentation thereof
• Stability of the functional and technical baselines
• Risks and progress on the risk mitigation strategies
• Financial baseline and performance
• Adherence to defined development approaches such as configuration or release management
• Education/training of the individuals who will maintain the system and their progress
• Change control and the inherent business decisions

Having a list of actions can be a valuable part of what a PM does each and every day.  When this action item list becomes the focal point of the day, the PM begins to loose the larger picture on the project and their capability to manage the project.  If a PM has the luxury of an assistant, the action item list is better suited for that individual.  As with most of my projects, this task falls to me but I spend a vast majority of my day focusing on elements such as defined in the list above.  This ensures I keep a good overall grasp on not only the technical aspects of the project but also the non-technical such as financials, human resources, change control, controling, and monitoring.

Issues Lists: Are they a good thing?

In many implementation and development methodologies, the concept of an issue list is prevalent and in many cases considered a critical component of managing a project.  This list is used to identify and track progress to closure of many different "issues" on the project including decisions by the business, detailed design or requirements questions, managment issues, etc.  The format and content of the lists vary as does the content of the lists.  Are these lists a critical component of managing a successful project or are they are common misconception that leads to unstable technical baselines and the downside of scope creep? 

This post will examine this question.  First, let's define some terms for the purpose of discussion.

Issue list - a set of questions, concerns, decision points that require resolution and specifically do not include issues found during the testing cycles which are commonly referred to as defects, bugs, trouble report, software trouble reports, etc.

Technical baseline -  a set of documents that uniquely describe both the requirements including business, technical, functional, and non-functional as well as the detailed technical designs on how to either develop software or enter meta data into a previously built commercial software package.

With these defintions in mind, the question remains are issue lists a good thing?  

One of critical aspects of managing a project is to understand the requirements, devise a strategy and plan for building the solution, then defining the solution to be built.  In the agile methologies, the order may be different but in all cases there is a starting point for developing software or implementing a commercial package.  When this starting point changes, the solution may change which we all know tends to extend the schedule even when we plan for that change as with agile.  This technical baseline becomes the guide.

A second critical aspect of managing a project is defining and maintaining this technical baseline.  When we create multiple documents which define the baseline, we create a situation whereby many documents have to remain in synchronization.  The difficulty of this situation increases expontentially as the number of documents in the technical baseline increase.  In a typical waterfall project, we have a requirements document and a small number of detailed design documents for solution components like interfaces, custom software, maybe some user exits, etc.

What happens when we write let's say a interface design.  Parties get together to review said document and identify a set of issues which we might maintain in an issues list.  Perfect, right.... Well maybe not...  The next logical step is to work the issues including status updates and proposed resolutions.  Eventually, we get the resolutions completed and documented in the issues list.

Now we have to go back into the detailed design document and integrate the issue resolutions into the design.  This seems unwieldy and redundant...  If we don't go back and integrate the issues resolutions with the design, we end up with a detailed design which has some of the design and a series of issue which have other parts of the design.  Even in an agile approach as the customer comments begin to mount, who and how does the project manager ensure all the issue resolutions are consistent and included in the solution.  How does it all fit together then becomes a problem.  In many cases during an agile project, the solution is the consolidated set of resolutions and a single location in which to look for the latest baseline.

Worst still is someone who is not familiar with the design has to read the design and all the issues which may apply then determine how they think the issues and design fit together which may or may not be the same interpretation as every one else.  These leads to confusion and an undermining of the technical baseline.

So what is a better way to handle?  In my experience, if something is important enough to make an issue, it should be recorded in some document that is part of the technical baseline.  This could be a requirements document, interface design, software design, etc.  When issues are defined, they are in context to some language in one of the technical baseline documents or is new language that should be in such a document.

Given this is true, how about maintaining the issues within the documents.  Most modern word processing or spreadsheet applications have a comment feature so issues can be documented in the actual documents. If an issues arises with Section x.y of the document, the individual identifying the issue enters a comment at the sentence(s) where the issue arises.  The side benefit is there is no need to define pointers into the source document or confusion around what langugage is being questioned as exists with an issue list as the pointer to the document and page must be included in the list.  This can be cumbersome and confusing in its own righ.  These issues are then worked in context to the overall design and language is integrated into a single document.

One downside to this approach.  Many project managers like to have a consolidated set of issues they can work and this solution makes that difficult.  I would suggest the upside to maintaining a stronger technical baseline far outweighs the extra effort required to manage through the technical baseline.  In a future post, I will discuss the concept of managing by lists.

The last point is there are a set of management activities commonly included on an issue list that should remain in a separate and consolidated list.  These issues include management activities not directly related to the solution.  Issues such as lack of VPN access, or developer needs a physical access badge for the building, visas needs to be approved, individual staff needs counseling, etc.  These issues are appropriate and I typically track as part of a periodic status report.