Skip to main content

Tag: Leadership

Stop! Who Needs the Power to Stop a Project?

Written by George Pitagorsky on . Posted in Articles. 1 Comment on Stop! Who Needs the Power to Stop a Project?

In some mind training methodologies there is a Stop exercise in which The aim is to immediately stop whatever you’re doing and freeze in that position, mentally, emotionally and physically, so that you can observe your current inner state. 

Project Momentum

There are projects that once they begin continue on like a snowball rolling down a snow covered hill.  The project builds momentum, increasing in terms of the time, effort and money that are continuously absorbed by it.  The greater the spend; the harder it is for the project to stop or change direction.

This may be fine if the project is of value and if the work is being done effectively so as to achieve the desired value.  Momentum carries the project to completion.

If, however, 1) the project is not adding value, perhaps because conditions have changed or the initial value proposition was incorrect, 2) if the project is headed in a wrong direction, or 3) it is not in compliance with policies rules, regulations and best practices then the project should be stopped.

In healthy organizations there are two types of people or groups that can stop a project.  The first is the sponsor, client or steering group and the second is a expert group or individual who is charged with making sure the project is going in the right direction and is complying with policies, regulations and best practices. 

When the sponsor, client or steering group stops the project it is usually stopped for good – “killed” or postponed until higher priority work is completed.  When an expert, architecture group or other gatekeeper stops a project it is often not a kill or postponement.  It is a pause during which the conditions that caused the stoppage are understood and cleared and the project set on course again. 

Of course stopping a project is risky, particularly if you are not an executive or client.  In some environments there is a process definition that allows for projects to be stopped by technical experts and project managers.  In many of these there is an unwritten rule – never do it, even if it should be done.  It’s just too political; someone will hate you for it.  In other environments, there is no provision in the process for anyone to stop a project.  In either case, projects become like undying vampires sucking the blood form the organization.

Stop the Line

In quality manufacturing cultures workers can stop the assembly line when they see something wrong. In the Toyota Production System Jidoka is one of two main pillars.  It means that people or machines can stop production lines in the event of problems such as equipment malfunction, quality issues, or late work. Jidoka helps prevent the passing of defects, helps identify and correct problem areas using localization and isolation, and makes it possible to “build” quality at the production process.

We need to apply this principle to project work.

Stopping a project for technical or quality reasons as opposed to business reasons a project does not mean killing it is a radical move since it means having project personnel stop work and thereby delay progress on the project. If they are full time the budget is affected; the meter is running.

Why would anyone want to do that?  The answer is simple; to draw attention to something serious and make sure it is addressed quickly.

For example, in a technology based project a group responsible for making sure that security and other operational standards are met needs the power to get the project manager or others to deliver information and sit for technical reviews early in project life.  Short of the ability to stop the project the review group often lacks the ability to get a resistant PM to cooperate or to take negative findings seriously.

How do we overcome the cultural and personal barriers to doing this?  We make sure that everyone understands their responsibility to say something if they see something.  We include appropriate gates in the project.  We make sure that people are not afraid of repercussions if they take their responsibility to heart and actually pull the emergency stop chord.

Don’t forget to leave your comments below.

Top 10 Leadership Qualities of a Project Manager

Written by Cynthia Low on . Posted in Articles. 2 Comments on Top 10 Leadership Qualities of a Project Manager

What qualities are most important for a project manager to be an effective project leader? It’s a question often asked and one that makes us sit back and think. Over the past few years, the people at ESI International, a leader in project management training, have looked at what makes an effective project leader. They quizzed some highly-talented project leaders and compiled a running tally of their responses. Below are the top 10 qualities in rank order, according to their frequency listed.

Inspires a Shared Vision

An effective project leader is often described as having a vision of where to go and the ability to articulate it. Visionaries thrive on change and being able to draw new boundaries. It was once said that a leader is someone who “lifts us up, gives us a reason for being and gives the vision and spirit to change.” Visionary leaders enable people to feel they have a real stake in the project. They empower people to experience the vision on their own. According to Bennis “They offer people opportunities to create their own vision, to explore what the vision will mean to their jobs and lives, and to envision their future as part of the vision for the organization.” (Bennis, 1997)

Related Article: Which of These Leadership Traits Do You Demonstrate?

A Good Communicator

The ability to communicate with people at all levels is almost always named as the second most important skill by project managers and team members. Project leadership calls for clear communication about goals, responsibility, performance, expectations and feedback.

There is a great deal of value placed on openness and directness. The project leader is also the team’s link to the larger organization. The leader must have the ability to effectively negotiate and use persuasion when necessary to ensure the success of the team and project. Through effective communication, project leaders support individual and team achievements by creating explicit guidelines for accomplishing results and for the career advancement of team members.

Integrity

One of the most important things a project leader must remember is that his or her actions, and not words, set the modus operandi for the team. Good leadership demands commitment to, and demonstration of, ethical practices. Creating standards for ethical behavior for oneself and living by these standards, as well as rewarding those who exemplify these practices, are responsibilities of project leaders. Leadership motivated by self-interest does not serve the well being of the team. Leadership based on integrity represents nothing less than a set of values others share, behavior consistent with values and dedication to honesty with self and team members. In other words the leader “walks the talk” and in the process earns trust.

Enthusiasm

Plain and simple, we don’t like leaders who are negative – they bring us down. We want leaders with enthusiasm, with a bounce in their step, with a can-do attitude. We want to believe that we are part of an invigorating journey – we want to feel alive. We tend to follow people with a can-do attitude, not those who give us 200 reasons why something can’t be done. Enthusiastic leaders are committed to their goals and express this commitment through optimism. Leadership emerges as someone expresses such confident commitment to a project that others want to share his or her optimistic expectations. Enthusiasm is contagious and effective leaders know it.

Empathy

What is the difference between empathy and sympathy? Although the words are similar, they are, in fact, mutually exclusive. According to Norman Paul, in sympathy the subject is principally absorbed in his or her own feelings as they are projected into the object and has little concern for the reality and validity of the object’s special experience. Empathy, on the other hand, presupposes the existence of the object as a separate individual, entitled to his or her own feelings, ideas and emotional history (Paul, 1970). As one student so eloquently put it, “It’s nice when a project leader acknowledges that we all have a life outside of work.”

Competence

Simply put, to enlist in another’s cause, we must believe that that person knows what he or she is doing. Leadership competence does not however necessarily refer to the project leader’s technical abilities in the core technology of the business. As project management continues to be recognized as a field in and of itself, project leaders will be chosen based on their ability to successfully lead others rather than on technical expertise, as in the past. Having a winning track record is the surest way to be considered competent. Expertise in leadership skills is another dimension in competence. The ability to challenge, inspire, enable, model and encourage must be demonstrated if leaders are to be seen as capable and competent.

Ability to Delegate Tasks

Trust is an essential element in the relationship of a project leader and his or her team. You demonstrate your trust in others through your actions – how much you check and control their work, how much you delegate and how much you allow people to participate. Individuals who are unable to trust other people often fail as leaders and forever remain little more that micro-managers, or end up doing all of the work themselves. As one project management student put it, “A good leader is a little lazy.” An interesting perspective!

Cool Under Pressure

In a perfect world, projects would be delivered on time, under budget and with no major problems or obstacles to overcome. But we don’t live in a perfect world – projects have problems. A leader with a hardy attitude will take these problems in stride. When leaders encounter a stressful event, they consider it interesting, they feel they can influence the outcome and they see it as an opportunity. “Out of the uncertainty and chaos of change, leaders rise up and articulate a new image of the future that pulls the project together.” (Bennis 1997) And remember – never let them see you sweat.

Team-Building Skills

A team builder can best be defined as a strong person who provides the substance that holds the team together in common purpose toward the right objective. In order for a team to progress from a group of strangers to a single cohesive unit, the leader must understand the process and dynamics required for this transformation. He or she must also know the appropriate leadership style to use during each stage of team development. The leader must also have an understanding of the different team players styles and how to capitalize on each at the proper time, for the problem at hand.

Problem Solving Skills

Although an effective leader is said to share problem-solving responsibilities with the team, we expect our project leaders to have excellent problem-solving skills themselves. They have a “fresh, creative response to here-and-now opportunities,” and not much concern with how others have performed them. (Kouzes 1987)

References:
Bennis, W., 1997. “Learning to Lead,” Addison-Wesley,MA.
Kouzes, J. M: “The Leadership Challenge,” Jossey-Bass Publishers, CA.
Norman: Parental Empathy. Parenthood, Little, Brown, NY.

Don’t forget to leave your comments below

Timothy R. Barry is a trainer and consultant for ESI International with more than 20 years of experience in project management. He has worked with over 40 major organizations worldwide .With over 20 years experience, ESI International is the world’s largest Project Management Training and Consulting provider. A comprehensive mix of project management, E-training, tailored corporate courses, consulting, assessment and mentoring means they are able to provide their clients with proven methods that enable them to achieve their goals. To put ESI International’s Project Management Solutions to work for your company, or for more information, call +44 (0)20 7915 5099 or visit the website at www.esi-intl.co.uk.

Project Success Plans – Planning for Success

Written by Gareth Byatt on . Posted in Articles. 2 Comments on Project Success Plans – Planning for Success

Co-authored by Jeff Hodgkinson and Gary Hamilton

“A Project Success Plan can be a platform for ensuring all project stakeholders start off, and continue on, the right footing.”

Setting up projects to succeed in the view of the customer/stakeholder is a critical part of the Project Manager’s role. We suggest that, as part of project planning activities in the early stages of your project, you should hold a Project Success Plan (PSP) meeting with all key team members to agree on the project’s goals, and to discuss the emotional success factors that will ensure the team gels successfully to deliver the required outcomes.

A Project Success Plan (PSP) is different from a Project Management Plan (PMP), sometimes referred to as a Project Execution Plan (or PEP). A PMP is a typically produced by the Project Manager to describe how the project will be managed and controlled in its delivery/execution phase, whereas the PSP is a documented meeting convened by the Project Manager to discuss and agree “what success means” to all key stakeholders. The PSP (like a PMP/PEP) should draw from project artefacts such as the Project Charter and the Customer Brief.

Project Success Plans can Help the Team to “Gel”

Have you ever managed or been involved in a project where, at one point or another, you felt that you were not on the “same page” as other team members? Ensuring everyone on a project team is continually pulling in the same direction can be a challenge. A Project Success Plan can help you to set a solid foundation for stakeholder interactions throughout the project, and to ensure you can detect and rectify any occurrences where stakeholder views and actions start to deviate off plan. In order to ensure everyone starts off on the right foot, it is important to kick off your project communications strategy properly. By this we mean, ensuring that everyone’s interpretation of success and their assumptions about the project are aired and discussed in an open group forum, which can be documented and evaluated in a Pareto-type chart format to indicate importance. This is the essence of the Project Success Plan.

The Project Success Plan is a communications planning tool in the project manager’s toolkit to get all key project stakeholders on the same page, and understanding each other’s prerogatives and drivers for success. This is not always an easy task, since there are likely to be a range of drivers and interpretations of project success amongst your stakeholders. For example, team members who are recipients of the end solution/product may have very different views and expectations of what project success means to those who are focused on delivering the product. It is also likely that some (or maybe all) team members in your project will be working together to achieve a specific objective for the first time. Indeed, the number of stakeholders who have worked together on projects before is an interesting statistic for the project manager to take note of at a project’s start. A Project Success Plan meeting should aim to achieve the following outcomes:

  • serve as an ice breaker for team members to get to know a little about each other
  • discuss and agree the basis for setting the criteria for achieving success;
  • team members agree and commit to their roles and responsibilities for the project;
  • everyone should understand each other’s personality and modus operandi;
  • everyone’s assumptions about the project and their drivers should be aired, discussed and documented;
  • a win/win philosophy and a collaborative approach throughout the project needs to be fostered,
  • the team should discuss their collective lessons learned from previous projects/experiences.

The points above are all about communication and common understanding. By understanding how to handle your key/extended teams’ communications with each other, stakeholders can avoid accidental and sometimes costly mistakes in communicating information and decisions during the project’s life. For example, ensuring that people discuss how meetings, reports and controls should be conducted will help set reporting expectations (e.g. if one person thinks project status reports are “a waste of time”, find out why and talk it through).

Because of the emotional focus of a Project Success Plan meeting, it should be held face-to-face whenever possible, however this may not be possible for smaller projects – particularly those that involve geographically disperse stakeholders. In such situations, a virtual conference meeting may be the most practical option. This requires special emphasis from the Project Manager in facilitating the meeting to validate everyone’s opinions frequently, ensure good feedback, and level set expectations for the project, since the important signs of body language will be missing.

The Timing of a Project Success Plan.

A Project Success Plan should be completed early in the project’s life, as soon as all key members of the project team are in place. Key members are those with a material interest and/or delivery focus in the project. The timing for holding a Project Success Plan meeting can typically be after initial set-up works are complete and the project reaches the start of its detailed planning phase. If stakeholders change during the course of the project, the project manager should include reviewing and updating the PSP with the new stakeholders as part of the Resource Planning.

A Project Success Plan can also be a tool the project manager uses to keep the team focused and engaged. When stakeholders are suffering from project fatigue, the project manager can refer back to the Project Success Plan and use it to motivate the team by reviewing the reasons for the project and what success means to each person.

How should a Project Success Plan be structured; Do All Projects Need One?

All projects will benefit from a Project Success Plan meeting, because it is a mechanism to ensure the following aspects are agreed to:

  1. Do we all agree on the core reasons for the project’s existence?
  2. Are we all on the same page? Can we agree how to work together (including our roles and responsibilities, team meetings and communication protocols, team member working styles, governance processes and expectations)?
  3. Are our assumptions about the technical aspects of the project (such as the design, scope, build methodology, work breakdown structure, schedule, budget and method of managing change) clear?

Large, complex projects have many different stakeholders, often spread across many geographic locations. A Project Success Plan for a large project may benefit from being led by a skilled facilitator, and it may need to last several days. Small projects with less complexity will typically not require the same level of detail.

The structure of a Project Success Plan meeting should ensure the emotional success factors are fully aired. It needs to bear relevance to the core Deliverables of the project regarding scope, budget, schedule and quality. An example of a Project Success Plan meeting agenda is shown below (the nature of your project’s Project Success Plan agenda will be tailored to the project):

Agenda Item
1. Project Introductions and Executive Summary
2. What is the definition of “project success”?
3. Our Project Methodology
4. Project Fundamentals, Principles & Key Drivers
5. Project Assumptions by us all, and how we all work
6. Project Scope, WBS, Schedule, Quality and Budget
7. Project meeting, governance and review strategy
8. Project Organisation and Role Definitions
9. Communications Management strategy
10. Tracking Benefits after Go Live

Conclusions

A Project Success Plan is a mechanism to achieve the following positive outcomes for your project:

  1. Ensure all assumptions about the project, and the meaning of success, are aired and discussed, and any misunderstandings and/or disagreements are resolved early in the project’s lifecycle.
  2. Ensure project team members get to know how to work with each other so that communications throughout the project are efficient and productive
  3. Assist the project manager in keeping the team focused and engaged, especially on projects of long durations.

Done well, a Project Success Plan meeting can help project managers and the entire team understand how to work together successfully, communicate well with each other, and be a tool to keep the team focused and engaged for the duration of the project.

Planning for success increases your likelihood of a successful project outcome. It is always important to ensure the “facts” of project scope, schedule, design, quality and budget are given due consideration. It is equally important to ensure the emotional aspects of project teamwork – team member expectations, their way of working, their personal aspirations for the project and their assumptions on how the project will unfold – are managed. A Project Success Plan is a method to bring out these emotional aspects. It can be a good platform to ensure the whole team continually pulls in the same direction to make your project a success.

Don’t forget to leave your comments below

Gareth Byatt is Head of the IT Global Program Management Office for Lend Lease Corporation. He’s a PgMP® and PRINCE2 practitioner, and holds an MBA and first-class undergraduate management degree. Gareth has 13 years of project and program management experience in IT and construction. He can be contacted through LinkedIn.

Jeff Hodgkinson is the IT Cloud Program Manager for Intel Corporation. He is a 30-year veteran of Intel with a progressive career as a Program/Project Manager. Jeff’s credentials include PMI’s PgMP® and PMI-RMP® (Risk Management Professional) Jeff was 2nd place finalist for the 2009 Kerzner International Project Manager of the Year Award. He can be reached through LinkedIn.

Gary Hamilton is the Manager of the PMO and Governance within Bank of America’s Learning and Leadership Development Products organization. Gary has 14 years of project and program management experience in IT, Finance and HR. He holds an advanced MBA degree in Finance and several certifications and credentials program management including PMI’s PgMP® (and PMP®.. Gary can be contacted through LinkedIn.

X-Gap: Using Strategic Planning to Close the Project Execution “Gap”

Written by James D. Murphy on . Posted in Articles. 4 Comments on X-Gap: Using Strategic Planning to Close the Project Execution “Gap”

Teams and organizations are constantly plagued by project execution errors and failures. These failures create an execution gap — a gap between what an individual and/or team plans to do and what they actually do instead. Just as retention rapidly degrades after learning, so does project execution after strategic planning. So what can be done?

In 1885, Hermann Ebbinghaus, a German psychologist, famously demonstrated a theory concluding that people start forgetting what they learn as soon as they learn it. In his “forgetting curve” study, he demonstrated that humans forget half of what they learn within an hour of learning it, and by the following day, they have forgotten a full two-thirds of the new information. Since Ebbinghaus’ study, psychologists have discovered that there are many ways to improve retention and memory; however, if memory is so fragile, what is its impact on project execution and strategic planning – getting the things done that you and your team should do? 

Strategic Planning: The Execution Gap Meeting 

Strategic planning is a form of team learning. When approached collaboratively, planning is a knowledge-creating and problem-solving process. And strategic planning can create much detail that is difficult to manage, and therefore, execute. Great project execution requires 100% retention in the team learning process. Without such a perfect level of retention, project execution will falter; however, just as there are techniques to improve individual retention after learning, there are techniques to improve the team’s project execution after strategic planning. One of these techniques is the Execution Gap Meeting, or X-Gap. 

In principle, the X-Gap is simple. Get the team together at regular intervals during the project execution phase, address the progress of each individual task that must be performed, and take action before progress falls behind. In “Teambuilding: Proven Strategies For Improving Team Performance,” recognized as the authoritative work on the fundamentals of team building, the authors note the importance of regular interventions within teams to prevent regression like that of the Ebbinghaus Forgetting Curve. Furthermore, they note that regression is more effectively halted when regular interventions are held to focus on tasks as a team rather than on a one-on-one, supervisor-to-subordinate basis. It sounds like a simple strategic planning technique; however, in practice, holding an effective X-Gap requires discipline.

One of the greatest challenges to leading an X-Gap is controlling the discussion and keeping it on task. Fundamentally, the X-Gap is a transparent strategic planning method of applying peer pressure to enhance project execution performance. So, participants have a tendency to provide excuses and open up lengthy discussions to distract the group from individual accountability. X-Gap leaders must fight this tendency.

Leading an effective X-Gap requires a commitment to four basic principles – focus, resolution, action and frequency.

Principle Number One: Focus

First, X-Gap meetings should be short and focused only on the tasks required. This strategic planning technique is not an opportunity for open discussion, complex problem solving or the exchange of general information. It has only one item on the agenda – the review of all due and open tasks within the plan. In an X-Gap, the leader convenes the meeting on time and proceeds task-by-task through the project by asking each task owner to report their progress.

Responses should be succinct. Completed tasks and tasks in-progress but not yet due are simply either “completed,” “on track,” or “green.” Tasks that are in progress but have some uncertainty about the capacity to complete them as planned are “yellow.” Finally, tasks that are past due or have encountered some critical obstacle that must be addressed are “critical” or “red.” The latter two classifications are the target of the X-Gap strategic planning meeting. The X-Gap leader’s purpose is to identify and isolate those “yellow” and “red” category tasks for further review.

Principle Number Two: Resolution

The second basic principle of the X-Gap is to take action to resolve uncertainty, ambiguity and any other obstacles. Once project execution gaps are exposed, the leader should make decisions and possibly reallocate resources in order to close those gaps. Some explanation and discussion is usually necessary. Therefore, X-Gap leaders must remain on their guard against unproductive, rambling discussions. Those responsible for the task targeted for discussion should succinctly explain the issue to the team and state what they believe they need in order to accomplish the task – to close the gap. This need is usually stated as a request for resources or a decision from the leader. 

At this point, teams will tend to want to have an open discussion about the matter; however, the X-Gap leader must contain this strategic planning discussion to only a few minutes. If the team is allowed to take too much time, then there will be less time to address other “red” and “yellow” tasks. As a rule of thumb, any task that requires more than two minutes to explain and discuss should be deferred to a separate discussion that takes place after the X-Gap meeting. Leaders must keep the X-Gap meeting focused and moving along smoothly so that all the relevant tasks within the plan are addressed.

Principle Number Three: Action

X-Gap meetings should identify specific actions that must take place during the project execution phase, unless all tasks are completed or on task as planned. Leaders should take care to either clearly indicate the actions that must take place as a result of the task review process, or indicate how and when decisions or other resolutions will take place and who is responsible for them. They must determine whether or not additional resources are required, who will acquire them and by when. And if further deliberation is required to achieve a decision, leaders must decide when this will take place and which team members will be a part of the discussion. Successful strategic planning in X-Gap meetings should never conclude without clarity about the next steps to take.  

Principle Number Four: Frequency

Finally, X-Gap meetings should be a recurring strategic planning event that aligns with the team or organization’s overall project execution rhythm. If the team holds an X-Gap every Monday morning at 10 a.m., for example, the team will be better able to anticipate, participate more fully, and prepare more thoroughly. 

Preparation is the key to a successful X-Gap meeting and strategic planning session. Team members report to the X-Gap at their pre-designated time and place with the statuses of their assigned tasks in the plan. This means being prepared to respond to its overall status, as well as providing both a succinct description of a status that is “yellow” or “red.” Participants should be prepared to answer the question: “What do you believe is required to move forward?” Of course, there are often certain dependencies outside an individual team member’s control that may be the underlying cause. Hence, the purpose of the X-Gap is to expose these project execution issues and address them appropriately as a team. Good preparation also means that individuals can stand in for others unable to attend the X-Gap, providing a status of their tasks and discussing what is needed to move forward.

An X-Gap strategic planning meeting must be led. As a teacher leads a classroom and utilizes techniques to help students improve retention, a leader should utilize techniques like the X-Gap to improve project execution

Don’t forget to leave your comments below.

Managing Small Projects; The Critical Steps

Written by Elizabeth Larson on . Posted in Articles. 6 Comments on Managing Small Projects; The Critical Steps

Co-written by Richard Larson

Small projects have unique challenges over larger ones. Because they’re small, it’s tempting to skip the planning process and start executing the work. This phenomenon is especially true if projects perform tasks similar to previous work, which in turn leads to a natural tendency to skip planning and to start doing the work. Then, essential steps are sometimes omitted, done out of order, or done later than desired. Likewise, costly mistakes can occur when risks are missed by executing too soon. A small project that isn’t planned enough can also ignore critical stakeholders, causing both resentment and rework.

Complicating the issue are project management methodologies and frameworks designed for large projects. Using such frameworks for small efforts is cumbersome and unnecessary. What is needed is a method that focuses on the essential steps and doesn’t waste time on overkill.

Related Article: The Greatest Challenges When Managing a Project

The following outlines the essential ingredients to managing small projects and how to successfully deliver project results every time. Our proven framework, and the critical steps for managing small projects combines years of practical experience with the core processes of the Project Management Institute’s Project Management Body of Knowledge (PMBOK®Guide).

In this article we present several issues related to managing small projects, as well as the framework. Several practical project templates for managing small projects are introduced and explained as to how they work with the critical steps of the framework. The intent is to help people deliver project results more quickly, better achieve desired objectives, and do so with less stress.

The major challenges we’ve seen in managing small projects are:

  1. Being able to recognize work that is really a project – and conversely to distinguish other kinds of work from project work, and manage it accordingly
  2. The lack of time taken to plan small projects when they are recognized as such, and to do an appropriate amount of planning (as opposed to the level needed for larger ones),
  3. Having the will or determination to follow a plan once it’s created for small projects, and
  4. Being disciplined enough to control and to track the project – and to see it through to completion.

Recognizing Small Projects

With the rush of day-to-day business in any sized company, it’s often difficult to separate project work from daily operations or regular, ongoing work. But projects or potential projects exist in all areas of a small or large business, and project work will suffer unless it’s identified and prioritized. Several issues surround the need for recognizing small projects:

  • Lack of time to think and plan. When work that is project work in nature gets executed as a collection of tasks without proper planning, there are several consequences. Organizations incur higher costs, deadlines get missed, staff and management get frustrated, and other predictable ill effects.
  • Unrealistic deadlines exist for all projects, but it seems especially so for small ones. Managers or internal customers frequently say “just do this” or “just do that” and don’t think through the consequences. People may not realize that the word “just” is a 4-letter word, and is a sign that a project is being instigated.
  • Communication neglect. Small projects usually have less communication in them and fewer status updates than their larger brethren. What often results is that sponsors then frequently forget they requested an initiative, which in turn results in wasted effort because the work goes for naught.
  • Sponsor disengagement. Sponsors quickly disengage on smaller projects if the efforts are not managed. Both neglecting communication and not engaging the sponsor are death sentences for small projects. According to recent research (see Standish Group report, 2001), the top factors for project success are executive support and user involvement, which applies equally to large and small projects alike.
  • Mixing operational and project work. People also have a tendency to meld project work with ongoing support or maintenance. Project work usually suffers because it is less urgent than operational work. In a related fashion, projects then never seem to end. Not closing projects has several consequences, including a) the work to maintain a product gets confused with project work that built it, b) missing capturing important lessons learned, and c) lack of team-building opportunities. Project closeout is just as important for small projects as larger ones.

Two small project examples will help illustrate some of the issues addressed here.

  • Internet Service Provider Project

An example of not recognizing an endeavor for a project was our company’s need to obtain a new Internet Service Provider (ISP). Our previous one had gone bankrupt, and informed us that they would be terminating service in a month. This was not welcome news, of course, and sent our operations manager into “react mode,” quickly thinking of what to do and then doing it. She is the type of person who thrives on chaos, and this was just another chaotic event. As her boss, I urged her to act quickly to get us another ISP. I had visions of our web access disappearing along with all our emails. We had to act quickly!

What’s wrong with this approach? Several things, actually. We did not recognize this effort was a project. The tight, externally-imposed deadline put us into a reactive mode, short-circuiting our planning. The reduced planning caused us several surprises along the way, such as being without email for a weekend, and one of our domain names didn’t accept emails for a week. It turned out that the old ISP shut down earlier than promised, a risk we had not addressed because of our haste. Plus, it was stressful on the whole company, and costly due to overtime by our network technician and potential loss of business. I’m sure every organization has had “projects” like this.

  • Bank Transfer Project

An example of successfully recognizing work as a project involved transferring our company’s bank accounts to a new bank and setting up a new deposit service. It helped that we were able to set an internal deadline, which gave us adequate took the time to plan properly. The planning we did allowed us to analyze risks and to anticipate problems with transferring the bank accounts. We set up risk mitigation plans which we fortunately never had to use, and the project ended smoothly and quietly, with no disruptions in service.

Lessons Learned

What did we learn from these two projects?

Not Recognizing a Project

 
 Recognizing a Project

 
■ No identified PM or sponsor meant unclear roles and responsibilities, leading to crucial steps skipped

 
 ■ Had a formal PM and a project plan, which led to complete planning of tasks

 
■ Time “saved” by not planning actually led to greater work and costly delays in service

 
 ■ Time spent planning was not burdensome and uncovered requirements and tasks

 
■ Risks were missed that were costly

 
 ■ Identified major risks and planned for them, adding steps that ensured success

 
■ Being surprised and doing rework was stressful and felt “hard”

 
 ■ Lack of surprises and executing the plan made it seem “easy”

 

Exhibit 1: Summary of lessons learned from recognizing and not recognizing small projects

Processes vs. Projects vs. Products

 

Organizations get work done through projects or processes. Both efforts work at initially building a product, in the case of projects, or recreating them, done through processes. Exhibit 2 shows the relationship between these key elements.

 

managingsmallprojects1
Exhibit 2: The productivity triangle: projects, processes and products

 
  • Business processes or procedures are pre-defined sets of steps to accomplish some business purpose. The components tend to be repetitive and repeatable between performers. And they have certain goals that “drive” them, like efficiency and accuracy.
  • Products, the second corner of the triangle, are things that are “built.” They are the output or deliverable of a company, or how an organization provides value. Products might be tangible, (as in manufactured products) or intangible (e.g., services or software). Inventing or creating products tends to be a one-time event (a project). Whereas the ongoing production or re-creating of a product is a process.
  • Projects, according to the PMBOK® Guide, are unique undertakings with a discrete beginning and end, that produce something new and valuable, and need adequate resources to succeed. Projects can and should be managed using a generic project management methodology separate from the product management methodology.

So, what does this all have to do with managing small projects?

 

First, a critical and not trivial issue in managing work effectively as small projects is simply to recognize them. One common reason for this phenomenon is that small project work is often intermingled with and mistaken for ongoing operational processes. The ISP example above illustrates this problem. The need to select a new ISP (the project) was mistaken for just another aspect of maintaining a web site and email access (the process).

 

This phenomenon also leads to a common complaint about small projects going on and on and on. If projects are not identified and separated from ongoing work, it is no accident that they appear to never end. And, when project work is identified for building of new products, the product management processes often take over, and a formal project management methodology is frequently ignored or intermingled with the product management one.

Roles and Responsibilities

 

Once a project effort is identified and before planning starts, a critical step in effectively managing small projects is to formally assign roles and responsibilities for them. That is sometimes hard, since people who are not used to being project managers are often reluctant to take on that role or are already overly busy with their normal operational or other work. But, the benefits heavily outweigh the disadvantages. Exhibit 3 summarizes the key roles for typical small projects.

Role Major Functions Typically Performed by
     
Sponsor Funding, direction Officers
    Directors
    Managers
     
Project Manager Manage project, Anyone
  Do project tasks  
     
Team Members Do project tasks Internal Staff
    Contractors
    Interns
     
Key Customers Provide requirements Internal staff

Exhibit 3: Roles/Responsibilities on Small Projects

The key roles, as with any project, are the sponsor and project manager. As stated previously, executive support and user involvement are the major contributors towards project success according to one study. The same study also cited an experienced project manager as another critical factor. (see Standish Report, 2001):

“Lack of executive support has replaced user involvement as the number one cause of project failure. Without a staunch project champion with a solid business vision, projects can drift into a technological or political abyss. Project stakeholders must create business value by improving customer service, communicating a clear business plan and delivering a competitive advantage.”

It would stand to reason, then, that the mere act of formally designating a project sponsor and project manager to a small project would contribute to its success. Yet, much project work gets completed without a formal PM which can often cause projects to be delayed or cancelled. The same Standish Group study found that for all “successful” projects, 97% of them had a formal project manager. Of the so-called “challenged” projects in the study, only 79% had Project Managers assigned. (see Standish Report, 2001).

  • Example: our company recently completed a major redesign to our web site. It was a substantial undertaking, and we gave what we thought was good visibility and support. However, due to budgetary constraints, we had to use a part-time project manager. When our first project manager got a new job and couldn’t continue, we changed project managers, and again had one part-time. As sponsors, the authors were also busy and were not exactly “engaged” in the project. It was no wonder the project stalled out, lost momentum, and was slowly withering away. Finally, we realized the trouble, and engaged ourselves again. We showed more interest and support for the project, held the project manager accountable for the project results, and the project got back on track.

Dr. Paul Dorsey writing in the InterNETalia Forum (see Dorsey article, 2003) in his article called “Top 10 Reasons Why Systems Projects Fail,” says “There do seem to be three factors that all successful projects have in common. Each of these factors is key to any project’s success. Each project can be viewed as a tripod. All three legs must be in place for the tripod to stand sturdily. In a systems project, these legs or critical success factors consist of the following:

  • Top management support,
  • A sound methodology,
  • Solid technical leadership by someone who has successfully completed a similar project.

Without each of these solidly in place, the tripod will topple and the project will fail.” (Dorsey, 2003)

It is obvious, then, that defining clear roles for small projects is as important on small projects as larger ones. What about other issues that differentiate small and larger projects?

Small vs. Large Projects

If work endeavors are recognized as projects, what differentiates small projects from larger ones? Here is a summary of some of the ways in which large and small projects differ.

Size Dimension Medium-Large Small
Time Number of hours example1: ≥ 1000 hours
example2: > 9 months		 < 1000 hours
< 9 months
Budget Dollars example1: ≥ $100,000
example2: ≥ $20,000		 < $100,000
< $20,000
Risks Number or type example1: “sizable” risks
example2: any risks		 “low-moderate” risks
no risks
Stakeholders Number or type example1: > 2
example2: Director level or above		 1 or 2
manager level or below
Visibility Level Typically high Often indistinguishable from ongoing work
Formality Level Sponsor, PM, team Named sponsor, PM, team Absent/informal sponsor/PM/team
1 person project teams

Exhibit 4: Dimensions used to Differentiate Small Projects from Larger Ones

When is Formal Planning Not Appropriate for Small Efforts?

So far we have dealt with the need for formalizing project planning for small projects. To summarize the major points, research and experience show that formal planning and control is most appropriate in these cases:

  1. For work that requires stakeholder requirements,
  2. Unique undertakings (which usually involves stakeholder requirements), and
  3. Work that puts an organization at some risk and for which planning would help mitigate that risk.

One can conclude that if the risks aren’t high enough or have enough impact, then the time and expense of formal planning isn’t worth the benefits. Or, project management is not needed if requirements are not needed, and the work can be performed according to previously gathered requirements.

  • Example: if an organization is audited by its Worker’s Compensation insurance agency, the risks inherent in performing the audit aren’t high. The risks born of setting up contractors, hiring employees, etc. have already been expended. So, by the time of the audit, the risks should be minimal and it’s not worth the effort setting up a project plan. The organization should appropriately respond to the audit and provide the information called for, but a formal project plan and execution are not appropriate.

A Project is Needed, Now What?

Once the need for formal project management on a small project is recognized and desired, the important next step is to begin formal planning. As stated earlier, though, project management frameworks designed for large projects are often cumbersome and counter-productive. A small project can be planned, executed and controlled with an appropriate level of process that focuses on the essential steps that add value.

Our own company has made considerable progress in employing a suitable small project framework. After numerous struggles, like the ISP example cited earlier, we made a concerted effort to adopt a project management approach of our own. We started with clarifying our corporate vision and strategy. It helped us immensely to prioritize projects, which is just as important in a small company as in a larger one.

Now when we decide to take on new projects, we work to link them to the strategic vision. And, if we have trouble doing that, then the project isn’t a good fit. On the other hand, potential projects may be a stretch for us and not what we normally do, But, if it fits our vision, we are more likely to try it, such as responding to customer requests for new products.

Framework for Managing Small Projects

Now let’s look at a practical approach, grounded in a Project Management Institute (PMI®) -based framework, for planning and executing small projects. Adopting this method for managing small projects was an important ingredient in our evolution to becoming a “projectized” organization.

Starting a few years ago, our company began using a formal project planning template that has helped us significantly to plan and manage our projects. After we clarified our vision and mission, and decided to become a “projectized” organization (and not just how to teach others how to do that!), a formal planning process and various templates were natural outgrowths. Both were based on several elements from PMI’s PMBOK® Guide.

We adapted PMI’s framework to this life cycle and supporting documents, with the intention of using it for all projects of approximately 25-250 hours. Many of our small projects are in the 40-80 hour range. For projects longer than 200-300 hours, we use a more formal planning process.

A big advantage of our templates for small projects is that they are short and stay focused on the major aspects of project management. We constructed them to be simple, both to minimize training and increase likelihood of people adopting it.

Another huge advantage of using our templates is that they work. The projects we or our clients have done using it – like the Bank Transfer project related earlier – have been much more successful than those without it – like the ISP project.

Steps

Once you’ve identified work that should be managed as a project, now it’s time to start planning and executing the project. Our method for managing small projects involves five basic steps. It’s derived from our own experience and based on the A Guide to the Project Management Institute’s Body of Knowledge, called the PMBOK® Guide for short. The five steps are project:

  1. Sanctioning.
  2. Scope Definition.
  3. Scheduling and Estimating.
  4. Status Reporting/Executing.
  5. Success – Closing the project.

1. Project Sanctioning

To be successful, all projects need to be sponsored and supported. The project sponsor owns it, and must approve its deliverables. Without this formal sanctioning of a project, it may be doomed to failure. The number one contributor to project success, according to a recent Standish Group Report (2001), is executive support. User involvement, experienced project managers, clear business objectives, and minimized scope are close behind as factors of successful projects.

Executive support for a project is documented through a project charter. A charter sanctions the project, and outlines what the sponsor expects the project to produce. It’s meant to be a business document, not a technical one, and is designed to be short. Ideally, the sponsor should create it, but, minimally, they should sign off on it.

As frequent project sponsors ourselves, we have found that slowing down long enough to create a charter forces executives to think through the need and vision for a project. Additionally, it often stops many a “good idea” from being delegated as a small project and forces the sponsor to justify the business need for the project. The graveyard of abandoned projects often comes from those good ideas that weren’t thought through well enough, and the instigator has gone on to the next “big idea.”

2. Scope Definition

The next step in managing a small project, and a natural follow-on to sanctioning it, is defining the scope. The scope statement defines the project’s:

  • business issues and their impact,
  • objectives (what the project should accomplish for the business), and
  • deliverables (including features in and out of scope).

In other words, it defines what is “in scope” for the project. The sponsor signs off on this document, too, and commits to it. Sponsors are responsible for and need to make the decisions about the extent of the project, while project managers are responsible for planning the project and reporting against the plan. It’s a distinction the authors as project managers have learned the hard way: it’s easy for sponsors to abdicate and make project managers responsible for scope decisions, and then blame the PM for expanding the scope and missing deadlines.

Another way to think about the scope is to think about it as the project manager’s answer to the sponsor’s charter. The scope statement interprets the business need and how the project will solve it. If it’s it done right, the sponsor can use it to verify if and how their vision will be carried out through the project. We use a simple template for the scope statement and combine it with the rest of the project plan for simplicity.

3. Scheduling and Estimating

Before starting a project, you also need to estimate how long it will take to accomplish the project objectives. For small projects, we suggest taking each deliverable and breaking it down to determine the tasks needed to produce each one. The resulting list of tasks is called a Work Breakdown Structure (WBS). The WBS helps you plan all the necessary work, and only the necessary work needed to meet the project objectives. It’s an essential tool for any size project. Breaking projects into smaller tasks makes it easier to estimate the time needed to perform the work, and it can be rolled up into an overall project estimate.

The project schedule guides the flow of work, to ensure things are done in the right order. Tasks for the schedule come from the WBS, and allow sequencing work so that:

  • Tasks will be done in the right sequence, reducing delays,
  • Tasks with no dependencies can be done in parallel with other project work, shortening the schedule
  • The longest sequence of tasks (called the “critical path”) will dictate how long the project will take.

Tools like Microsoft Project® provide valuable assistance in estimating and scheduling projects and in calculating the critical path. For projects without many dependencies, simple tools like Microsoft Excel® and Microsoft Word® do a decent job of recording a schedule.

4. Status Reporting/Executing

This step is finally where project work begins. By now you’ve scoped out the project, divided it into deliverables, broken it into tasks, and created a schedule. It’s time to work the plan.

On larger projects, experts say 90% of a project manager’s time is spent communicating. For smaller projects, especially when the project manager is doing some or all of the work, the communication time is obviously much less. But, it is essential to communicate project status as it is executing. We suggest weekly status reports to the sponsor, describing:

  • What has been accomplished since the last report,
  • How much time and money have been spent,
  • Variations from the budget or schedule
  • Any project issues that have arisen.

5. Success – Closing the Project

As each deliverable from the scope statement gets completed, take the opportunity to celebrate success. Of course, the sponsor should approve each deliverable first. After all deliverables have been approved, the project can be closed out. This step is important because it gives you one last chance to celebrate, and feel good about what the project has accomplished. It’s a great morale boost that beats being rewarded by more work immediately!

Equally important, closing out a project is the time to do a Lessons Learned session with the project team. A Lessons Learned meeting recaps what went well on the project and what could be improved for the next one. Both are valuable for capturing knowledge acquired during the project that can be built on in the future. The lessons learned can be listed on a close report, which is also useful for summarizing project time, cost, and variances from the budget and schedule.

Putting it All Together

At first, going through the steps feels a little awkward and unnatural. After one or two efforts, though, people usually start seeing the benefits and the awkwardness disappears. Then, a scary thing starts to happen. People hold off starting on work until they get a project charter. Or, team members look forward to lessons learned sessions and celebrating the end of a successful phase or project closeout. Then, you know you’re on your way to “tech success” and can stop playing that hero role so much. You get more sleep and get to see your kids more that way, too.

References

The Standish Group, (© 2001) “Extreme Chaos Report,” p. 1. https://www.projecttimes.com/wp-content/uploads/attachments/extreme_chaos.pdf
Dorsey, Dr. Paul (3/25/2003), “Top 10 Reasons Why Systems Projects Fail,” http://www.datainformationservices.com/DIS/Forum/topic.asp?TOPIC_ID=17

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP and Richard Larson, PMP, CBAP, are Principals of Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Contact us at 800-646-9362 or at www.watermarklearning.com.

For a copy of any of the documents mentioned in this article, send an email to the authors. They can be reached at [email protected] or [email protected]. 10/21/09