A New Perspective

In the past two years I’ve had an opportunity to be a project team member rather than managing the project team. Not by design but certainly a positive move. It provided a new perspective of the  project manager role, how an independent review can add value, the criticality of the project manager, technical lead and business analyst relationship and what it is like to participate as a team member. This opportunity was humbling and increased my respect and gratitude for strong team members while giving me insight into how I, as the project manager, can enhance their experience by serving as a leader of the project through facilitating competent project team member.       

When the opportunity to be a Quality Assurance Engineer for projects presented itself I thought “Why in the world would I want to do that”? I hadn’t performed that type of role and didn’t know if it would be fulfilling or enhance my career. After taking some time to think it through I saw it as a way to rediscover participating on a project rather than managing the effort. It would free me to explore the world of project management from a different perspective. I’d mentored and coached project managers from a program manager and direct manager position and saw this role as an independent peer review of project activity as part of the project team. I decided to make the move. This was a way to mentor and coach project managers in the specific areas of methodology tailoring, risk and issue management and stakeholder management.

Having managed Programs/Portfolios, developed Program Offices and been an IT Executive I thought of this as a step down. I’m sure that is how it is seen by many professionals. It wasn’t long before I concluded that it was a perpendicular move rather than a step down. I spent my time working with the IT Stakeholder and the Project Manager managing the project management process. Gate reviews were enhanced and I added a different level of value than I might have as the Program Manager, the Project Manager or the manager of the Project Manager. My value was in the relationship with the IT Stakeholder as an independent project consultant.

Now that I’m managing projects again I have an opportunity for a makeover. I recognize changes in my project management style. My role with IT Stakeholders has changed and my role as a team member is what I’ve come to enjoy the most. What has been confirmed most is the relationship between the competence of all team members and the successful delivery of the project.

While I have to be able to answer questions on overall project health and am accountable for the delivery of the solution, I cannot make up for poor performance. My responsibility is to ensure poor performance is identified, eliminated or project adjustments are made. Just as I would change expectations or fire someone for poor performance in my personal life, my responsibility is to facilitate the resolution of performance issues, not make up for them by trying to play a role other than project manager.

Read more...

Project Management Checklists

Checklists have been around a long time as a project management tool. There are checklists for everything from initiating to closing a project. Checklists are an important part of preparing to move forward and validating accomplishments. The problem I have with checklists is that they are used too frequently, and they are relied on too heavily as static pieces of information. I’ve seen many failed projects with a multitude of checklists. A balanced approach to using checklists is critical.

Some examples of useful checklists outside of the realm of project management may be useful to show a healthy application. I’ve used a checklist when packing for travel for years. Interestingly enough I’ve always created the checklist before each trip. I know that some folks use a template and some start from scratch each time. Whether you’re a template person or not, reviewing the checklist to make sure you have everything for your trip is good advice. I use a recipe as a checklist to make sure I have all the ingredients. These two checklists serve different purposes. The recipe checklist is used to ensure that the result is the same every time. The travel checklist is to ensure the result is right for the specific trip being taken.

Checklists in project management can serve different purposes as well. It is when checklists are used like recipes that project managers get into trouble. Here are some guidelines for using checklists.

Checklist as a Planning Tool

Use the following questions when using a checklist as a planning tool. First up is “Do I need to do the item on the list?” When this question is omitted work is done that may not add value to the project, this is a waste of dollars and effort and can frustrate the Sponsor, Stakeholders and Team. Make sure you are doing only the work that adds value. It is like packing a winter jacket when going to Hawaii – it isn’t used and just adds weight. The second question that needs to be asked is “Is there anything that isn’t on the list that must be done?” This question should be asked every time, whether conducting a project such as repetitive roll out once the product is developed or new development, there is always something associated with the effort that could be different.

Checklist as an Inspection Tool

Establishing a planning checklist is only part of the equation. The checklist becomes an inspection tool once the contents have been established. An inspection tool is valuable to the project when it is relevant. That implies a continuous review of the checklists’ content. By that I mean a validation that the work that has been identified is still needed as changes to the project occur. Without that review, work is done that is not needed and work that is needed is not done.

Project managers who are new to the craft rely on checklists as guideposts. The issue is not their use, the issue is using them without due diligence. As the Project Management Institutes Project Management Body of Knowledge (PMBOK) suggests, using expert judgment and historical information is a must throughout a project. Checklists are no exception.

Ride On, Manage On

Read more...

Agile Principles and Project Management

I attended my PMI chapter meeting last evening. The presentation was about agile principles and project management. Since agile project management is such a hot topic I thought I’d give a quick critique of the presentation and the topic in general.

Let’s start with the things that annoy me about this topic and then get to the good stuff. My biggest complaint is that people who present this topic seem to slam the traditional form of project management. I don’t suggest that the traditional form is fantastic. Like I’ve said, project management has changed over time and continues to evolve, much like the manufacturing processes have changed. I am not sure what the value is to the audience, since most of the audience practices traditional project management it can be a bit offensive. Next up is that there is not context given to the agile principles that they believe can be adapted for traditional project management nor do they mention that some of the principles have been used, to some extent, in traditional project management in the past. There is no mention of the fact that agile requires the principles to work. That being said, the practices that the speaker mentions are good practices for traditional project management.

The two fundamental points that formed the basis of the presentation are that agile represents a more active management approach than traditional project management. I’m not sure I agree. Either I’ve been managing projects incorrectly or counter to the suggested method or that is an agile message that folks who practice agile use to provide the perspective that they are agile. Second, the premise is that agile is meant to help project teams “fail faster” and accentuated four points; closed feedback loop, increased control, a strong and well maintained team structure and identification of issues sooner.

Some principles were omitted and should be mentioned because their supporting concepts differentiate agile software development from traditional delivery. A couple of the principles have to do with the management style and how the team is viewed. First, the team members are considered motivated and should be trusted to do the next right thing and the team members are self-organizing, they are not assigned work as much as they assign themselves work. The second group of principles has to do with the technical aspects of delivery, which are to have rapid continuous delivery of useful working software and to ensure that technical excellence and design are part of the rapid delivery (can’t cut corners). These principles are more difficult to adapt to a traditional project management method, and I believe they deserve some exploration in future posts.

Ride On, Manage On

Read more...

There are two kinds of motorcyclists, ones that have had a mishap (accident, falling) and one that hasn’t had one yet. One thing every new motorcyclist learns is that, at some point in their motorcycling career, they will drop their motorcycle. When I started riding, I knew it was just a matter of time before I fell. The same can be said of project managers. At some point in their career, they will have a project that falls. The extent of the damage to the project and the project manager, just as in the case of motorcyclist and motorcycle, is based on the amount of risk that the person took on for the effort.

Projects aren’t conducted in isolation, which means that the environment will change, sometimes for the good and sometimes, well, in the opposite direction. I haven’t met a project manager yet that has a perfect record of “on time, on budget, with quality delivery” for every project they’ve managed. I have met many project managers that have managed to avert disaster, where the project was not considered a failure, although it wasn’t considered a success either. Project errors, mistakes, miscalculations are part of maturing as a project manager. We have “opportunities” for growth where our best laid plans meet with unforeseen circumstances. These project errors are part of project management.

The trick to being a successful project manager is to manage the project difficulties and avert project disaster. The characteristics of the project managers that have been most successful in their careers have been those that have managed to stay “out of harms’ way”. There are some specific skills that these successful project managers have that have helped them to deliver projects successfully.

First, they know their stakeholders. That is more than identifying the stakeholders and capturing their needs and expectations. They have gone beyond those tasks and are able to identify the significant few, those that require more attention because of their role in the organization, their expertise for the specific project, or their influence. The project manager connects with those specific individuals differently than with the rest of the stakeholders. Obtaining direction, buy-in and support from those stakeholders can make or break the perception of success or failure of a project manager or a project. Since perception is reality, their backing is critical.

Second, they understand risk. It isn’t that they identify risks and perform the risk tasks. They understand the cumulative nature of risk and make specific choices about how to frame a project, present information on a project and strategically manage the project. They have mastered the art of ownership of project risk and are firm regarding the degree of risk that they believe is appropriate for the project they are managing.

Third, they can communicate project information accurately to the right people at the right time. They don’t cry wolf and they don’t cover potential problems. They are transparent in the communication and are not willing to gloss over potential problems and are willing to stop a failing project.

These are not the only reasons a project manager is successful. I would say these are my top 3. Know your stakeholders, know how to manage a risk portfolio and be able to communicate effectively. When you don’t have the right backing and the risk is above tolerable levels it won’t matter how good you are at controlling the other aspects of the project.

Ride On, Manage On

Read more...

Project Systems

One thing I've learned from managing a large number of vastly different projects is that creating the appropriate project system is one of the ways a project manager adds value. The project system is made up of the relationships, methods and tools for the project. The components of the system are what provide the structure for the project. The interdependence of the relationships, methods and tools provide the boundaries inside which the project team can achieve the objectives of the project. Without these components, project teams struggle to know how to work together, which usually contributes to project failure.

Project systems are evolutionary. The reasons for this evolution are rooted in the fact that most projects are designed to make money, to save money, or to avoid spending more money than necessary. It wouldn't be necessary to have any form of project structure except one type if it weren't for money. The newer structures are designed to enhance the projects' ability to deliver value sooner. The project system is a value proposition and there will continue to be growth and evolution to provide value at the earliest possible moment based on the project. Project management will evolve in conjunction with the project systems to continue adding value to project delivery.

Projects aren't conducted in a vacuum. Every organization has multiple active projects at any given time, which suggests that, as project systems evolve, an organization must evolve their program and portfolio management. This dynamic suggests that project managers must be knowledgeable about more than just project management. Project managers must understand how the organization handles the programs and portfolios since the methods used will impact the types of project structures that will work best for an individual project.

The simple truth is that each project is unique, which causes each project system to be selected based on the unique qualities of the project. Which structure to use for a project is determined by the following factors (not a complete list):

The level of experience and competency of the team members

The size and complexity of the project

The maturity of the Project, Program and Portfolio Management

The culture of the organization

The risk tolerance of the customer

The number of stakeholders

When we view projects as systems acting within a portfolio management system it becomes easier to identify the best structure for the project. Employing predictive, adaptive or extreme methods to achieve value quickly is only possible by considering the entire system. Creating the right project system allows team members to work at the highest level possible, allows adaptation to change occur, and support the customer in the right way. No method is the best method for all projects, there is a "good, better, best" selection that, when made, enables success.

Ride On, Manage On

Read more...