The Nature of Project Management

Why do many talented developers and IT professionals consider project management to be an obstacle, rather than an enabler? Why do clients often resist project oversight or try to minimize it? Does project management really allow projects to reach completion more quickly, or are speed and project discipline mutually exclusive?

We’ve explored the balance of speed and delivery and the nature of innovative projects in recent articles. Let’s tie these themes together and review techniques that help keep project management relevant to even the most unique and innovative programs.

Project bureaucrats

When I teach project management, I often draw a distinction between project managers and project bureaucrats. We’ve all had encounters with project managers who turned into bureaucrats. Project bureaucrats are more interested in ensuring that every step of the methodology is applied and every line of every form is filled in than in what’s actually happening on the ground. On the other hand, it’s common to meet project managers who apply minimal project methodology, yet, through their expert use of relationships and personal interactions, always seem to know exactly where the project stands.

In my experience, it’s the project bureaucrats who often leave a bitter taste with both the delivery team and the client. These project managers turned bureaucrats have forgotten one of the key rules of project management: don’t mistake the map for the journey. All the plans, charts, and milestones mean nothing if they aren’t consistent with the reality on the ground. And there’s the rub; especially in innovative projects, the plans and estimates are often based on a fallacy — there’s the idea that we can predict the progress of something that’s never been done before.

Project spec compliance = success? Not always

In his outstanding book Agile Project Management, Jim Highsmith offers two examples that emphasize the point. The movie Titanic, from a project management perspective, was a huge failure — over budget, over schedule, and plagued by unforeseen risks that threatened to derail the project at every turn. Motorola’s Iridium project, which spent billions of dollars launching satellites into orbit in order to make telephone service available worldwide, was a great project management success. Yet the market is the ultimate judge, and the project management compliance of Motorola’s venture didn’t save the project from failure, nor did the project management disaster (no pun intended) of Titanic’s production taint the film’s appeal to the public.

The lesson that project managers should learn from these examples is that compliance with project specifications does not constitute project success; in the ultimate analysis, only business results matter. Stated another way, the largest risk in any project is not that it will deviate from plan; it’s the risk that the final outcome won’t fulfill the real need. Predictive methodologies, such as the techniques championed by the Project Management Institute in its PM Body of Knowledge, can add tremendous value, especially for projects for which we have a historical basis to look to for precedent. For truly innovative projects, in which any prediction is little more than guesswork and for which we’ll be inventing never-before-seen products, we need to look for a new approach. Hence, the growing popularity of agile approaches.

Agile myths and truths

The central insight of agile methods is not that project overhead is a pain in the neck or that programmers like to be free; instead, it is the observable truth that, especially in innovative programs, customers can’t describe what they want until they see it, and prediction is inappropriate when there’s no way to visualize what the final result will be, let alone exactly how long it will take to build.

Unlike predictive methods, in which the planning, estimating, and risk assessment activities are all front-loaded and often are seen as a separate “planning” phase, agile approaches assume that the requirements will grow incrementally and iteratively as the project proceeds. This emphasis on “just enough” planning and requirements discovery is an acknowledgement of the fact that the key up-front activity in an agile approach is the creation of the first iteration of the product, so that the sponsor can see it and touch it, and discrepancies between the sponsor’s vision and the product created by the team can be modified to fulfill the current business need.

Agile project management is often misunderstood, as illustrated by the proliferation of articles about “agile myths.” Agile methods are not about “buying pizza and getting out of the way,” as these methods are often caricatured. Agile methods, from SCRUM to Highsmith’s APM Framework, are disciplined and structured approaches to product development, just as predictive methods are; these methods just address different types of problems.

Predictive and agile approaches have robust requirements discovery techniques, but agile methods acknowledge that requirements will evolve throughout the life of the project rather than up-front. Both approaches have stakeholder participation practices, but agile methods insist that stakeholders and sponsors are involved throughout the project in a collaborative, interactive manner. Predictive and agile both have mechanisms for integrating changing requirements into the plan, but the approaches use different techniques. Predictive techniques often apply restrictive change management procedures. Agile methods are specifically designed to encourage and implement beneficial change by providing an iterative, incremental approach to development focused on implementing, rather than controlling, positive change.

Innovative projects call for innovative methods, but that doesn’t imply, as many agile skeptics insist, that the benefits gained by applying structured project management techniques must be abandoned. Agile approaches are appropriate for creative, inventive projects because the methods integrate exploratory, collaborative techniques into the project process and acknowledge the mutating nature of exploratory IT projects into the PM methods we apply. Even PMI, in its newly published Body of Knowledge, recognizes the value of the iterative, incremental approaches advocated by agile proponents.

More to come

In subsequent columns, we’ll dig a bit deeper into the specifics of some of these techniques and explore ways that agile approaches can be combined with familiar, predictive techniques to apply exactly the right level of rigor to the project, no matter where it falls on the innovation spectrum.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

Rick Freedman is the author of three books on IT consulting, including “The IT Consultant”. Rick is a Director in the Global Services Division of NEC America, and a trainer and course developer in the Agile Project Management practice of ESI, the international PM training company.

Organizational Influences on a Project

Projects are typically part of an organization that is larger than the project.

Examples of organizations include corporations, government agencies, healthcare institutions, international bodies, professional associations, and others. Even when the project is external (joint ventures, partnering), the project will still be influenced by the organization or organizations that initiated it.

 

The maturity of the organization with respect to its project management system, culture, style, organizational structure and project management office can also influence the project. The following sections describe key aspects of these larger organizational structures that are likely to influence the project.

 

I have worked as a Project Manager in all of these types of organizations. There are pros and cons of each listed below. It is vital that the organizational structure is clear and known to all for the project to run smoothly.  

 

Project-based organizations are those whose operations consist primarily of projects. These organizations fall into two categories:

 

• Organizations that derive their revenue primarily from performing projects for others under contract – architectural firms, engineering firms, consultants, construction contractors, and government contractors.

• Organizations that have adopted management by projects. These organizations tend to have management systems in place to facilitate project management. For example, their financial systems are often specifically designed for accounting, tracking, and reporting on multiple, simultaneous projects.

 

Non-project-based organizations often may lack management systems designed to support project needs efficiently and effectively. The absence of project-oriented systems usually makes project management more difficult. In some cases, non-project-based organizations will have departments or other subunits that operate as project-based organizations with systems to support them. The project management team should be aware of how its organization’s structure and systems affect the project.

 

Organizational Cultures and Styles

Most organizations have developed unique and describable cultures. These cultures are reflected in numerous factors, including, but not limited to:

• Shared values, norms, beliefs, and expectations

• Policies and procedures

• View of authority relationships

• Work ethic and work hours.

Organizational cultures often have a direct influence on the project. For example:

• A team proposing an unusual or high-risk approach is more likely to secure approval in an aggressive or entrepreneurial organization

• A project manager with a highly participative style is apt to encounter problems in a rigidly hierarchical organization, while a project manager with an authoritarian style will be equally challenged in a participative organization.

 

Organizational Structure

The structure of the performing organization often constrains the availability of resources in a spectrum from functional to projectized, with a variety of matrix structures in between.

 

The classic functional organization is a hierarchy where each employee has one clear superior. Staff members are grouped by specialty, such as production, marketing, engineering, and accounting at the top level.

Engineering may be further subdivided into functional organizations that support the business of the larger organization, such as mechanical and electrical.

 

Functional organizations still have projects, but the scope of the project is usually limited to the boundaries of the function. The engineering department in a functional organization will do its project work independent of the manufacturing or marketing departments. When new product development is undertaken in a purely functional organization, the design phase, often called a design project, includes only engineering department staff. Then, when questions about manufacturing arise, they are passed up the organizational hierarchy to the department head, who consults with the head of the manufacturing department. The engineering department head then passes the answer back down the hierarchy to the engineering functional manager. These organizations are good for having a clear career path for project team members when the project ends.

 

Projectized organizations have team members that are often collocated. Most of the organization’s resources are involved in project work, and project managers have a great deal of independence and authority. Projectized organizations often have organizational units called departments, but these groups either report directly to the project manager or provide support services to the various projects.

 

Matrix organizations are a blend of functional and projectized characteristics. Weak matrices maintain many of the characteristics of a functional organization and the project manager role is more that of a coordinator or expediter than that of a manager. In similar fashion, strong matrices have many of the characteristics of the projectized organization, and can have full-time project managers with considerable authority and full-time project administrative staff. While the balanced matrix organization recognizes the need for a project manager, it does not provide the project manager with the full authority over the project and project funding.

Such a team may have many of the characteristics of a project team in a projectized organization. The team may include full-time staff from different functional departments, may develop its own set of operating procedures and may operate outside the standard, formalized reporting structure.[i]

 

---

[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition

32 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

 

Manage Your Stakeholders! The Key to Your Project’s Success!

 

Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. Take it from me – these are the people you need to pay the most attention to. They need to be identified in your planning – especially in your communication plan.  They may also exert influence over the project’s objectives and outcomes. The project management team must identify the stakeholders, determine their requirements and expectations, and, to the extent possible, manage their influence in relation to the requirements to ensure a successful project. They can make or break a project!

 

Stakeholders have varying levels of responsibility and authority when participating on a project and these can change over the course of the project’s life cycle. Their responsibility and authority range from occasional contributions in surveys and focus groups to full project sponsorship, which includes providing financial and political support. Stakeholders who ignore this responsibility can have a damaging impact on the project objectives.

 

Likewise, project managers who ignore stakeholders can expect a damaging impact on project outcomes. Sometimes, stakeholder identification can be difficult. For example, some would argue that an assembly-line worker whose future employment depends on the outcome of a new product-design project is a stakeholder. Failure to identify a key stakeholder can cause major problems for a project. For example, late recognition that the legal department was a significant stakeholder in a year 2000 rollover (Y2K) software upgrade project caused many additional documentation tasks to be added to the project’s requirements.

 

Stakeholders may have a positive or negative influence on a project. Positive stakeholders are those who would normally benefit from a successful outcome from the project, while negative stakeholders are those who see negative outcomes from the project’s success. For example, business leaders from a community that will benefit from an industrial expansion project may be positive stakeholders because they see economic benefit to them community from the project’s success. Conversely, environmental groups could be negative stakeholders if they view the project as doing harm to the environment. In the case of positive stakeholders, their interests are best served by helping the project succeed, for example, helping the team to acquire the needed permits to proceed. The negative stakeholders’ interest would be better served by impeding the project’s progress by demanding more extensive environmental reviews. Negative stakeholders are often overlooked by the project team at the risk of failing to bring their projects to a successful end.

 

Key stakeholders on every project include:

 

• Project manager. This is the person responsible for managing the project.

• Customer/user. This refers to the person or organization that will use the project’s product. There may be multiple layers of customers. For example, the customers for a new pharmaceutical product can include the doctors who prescribe it, the patients who take it and the insurers who pay for it. In some application areas, customer and user are synonymous, while in others, customer refers to the entity acquiring the project’s product and users are those who will directly utilize the project’s product.

• Performing organization. This refers to the enterprise whose employees are most directly involved in doing the work of the project.

• Project team members. This is the group that is performing the work of the project.

• Project management team. These are the members of the project team who are directly involved in project management activities.

• Sponsor. This is the person or group that provides the financial resources, in cash or in kind, for the project.

• Influencers. People or groups that are not directly related to the acquisition or use of the project’s product, but due to an individual’s position in the customer organization or performing organization, can influence, positively or negatively, the course of the project.

• PMO. If it exists in the performing organization, the PMO can be a stakeholder if it has direct or indirect responsibility for the outcome of the project. In addition to these key stakeholders, there are many different names and categories of project stakeholders, including internal and external, owners and investors, sellers and contractors, team members and their families, government agencies and media outlets, individual citizens, temporary or permanent lobbying organizations, and society-at-large. The naming or grouping of stakeholders is primarily an aid to identifying which individuals and organizations view themselves as stakeholders. Stakeholder roles and responsibilities can overlap, such as when an engineering firm provides financing for a plant that it is designing. Project managers must manage stakeholder expectations, which can be difficult because stakeholders often have very different or conflicting objectives.

 

For example:

 

• The manager of a department that has requested a new management information system may desire low cost, the system architect may emphasize technical excellence, and the programming contractor may be most interested in maximizing its profit.

• The vice president of research at an electronics firm may define new product success as state-of-the-art technology, the vice president of manufacturing may define it as world-class practices, and the vice president of marketing may be primarily concerned with the number of new features.

Five Keys to Great Relationships!

Everyone has had the experience of “connecting” to someone almost immediately when you meet. This is the art of building solid relationships. When you feel this connection you are glued to the conversation and sometimes can finish each other’s sentences.

 

Just about everything you do relies on teamwork. It is vital to a well working Project team, a family, lasting friendships etc. These are five things to look for in a solid relationship:

 

1.   Respect: Everyone wants to feel important and that they matter. The key is that you show respect to others even before they have done anything to warrant it. You respect others because they are simply human beings. At the same time, you should have to expect to earn it from others. This makes working through conflicts much easier.

2.   Shared Experiences: Respect can lay the foundation for a good relationship, but it’s not enough. You can’t be rational with someone you don’t know. It takes shared experiences over time. This is easy in families, but if you have a project team with high turnover, you need to work at building those relationships.

3.   Trust: When you respect people, and build shared experiences, you are in a position to develop trust. It is essential to every relationship.

4.   Reciprocity: One sided relationships don’t last long. If one person is the giver and one person is the receiver, there is no win-win dynamic. You should ask your teammates, colleagues and friends about their dreams and hopes. Give people your full attention and look them in the eye when you are in conversation.

5.   Mutual Enjoyment: When relationships start to grow really solid, the people begin to enjoy each other. Just being together can turn unpleasant tasks into positive experiences. Becoming a master at building relationships brings individual and team success.

The Project From Hell

 

Problem

I know all of you have had a project from hell. Mine was a project that had 4 releases before I took it over, so I had no ability to pick my team. The team dynamics had gotten so bad, and the code was so buggy, that the sales people wouldn’t sell the product!

My approach

This is the approach I took. I interviewed everyone involved in the project and quickly found out that the main problem was the technical leader. No one liked working with him and he thought he was the God of engineering. The technical writer was ready to go to HR with a charge of sexual harassment. That I had to inform the VP of engineering and the VP of HR in case the charge was made real and we had a legal issue on our hands.

I also worked extensively with the technical leader in the areas of communications and relationship building. The two of us were able to work well together, but somehow he couldn’t translate it to the rest of the team. He didn’t even know when he committed something that would be taken the wrong way. Whenever that happened, I immediately gave him feedback in the hopes he would start to learn to recognize these situations before they incurred and change his behavior.

Using other eye’s to help

When that didn’t work, I brought in a consulting team to help us agree on a mission, goals, roles and how we would run meetings. I invited people from all disciplines; software engineering, technical documentation, first and second level support, sales, marketing, services and quality.

The meetings were heated but we all were able to come up with an agreeable way to run the project. When we had a 3 month checkup with our consulting team, we were not doing much better. It came to the point where one of the support members verbally abused me in public. I had to make a decision, so I told the technical leader that his expertise was needed as a technical guru, but that I was give the project lead role to someone else on the team. Things slowly became better. The project team met to decide how to make the product more supportable and profitable. (Upper level management was ready to cancel the project at this point). We came up with a plan to have the people who knew the code best to do a massive code review and pick the hot spots that had to be rewritten.

The technical leader ended up leaving because it was his complicated, uncommented code that was causing the most problems.

Great ending

But there was a good ending. I presented this plan to upper management (which would take us a year without releasing while we were rewriting the code) expecting them to reject it. When we got the go ahead – we knew failure was not an option.

We included the whole team to draft a set of metrics that the code had to pass and refused to release it until the key support personnel gave it the ok. One of my inputs to these metrics was constant communications to the point that we met every day to plan the next day’s activities. We won a prize within a year for raising sales so dramatically.

That was my hardest project, but we all learned a lot. My only regret was that I couldn’t save the technical leader. He was very brilliant, but refused to mentor anyone of the team. My message to you is there is no project that is impossible.

 Have a great day! Donna

What Goes Into a Project Plan?

What goes into a Project Plan?

1.   The Scope Management Plan: This is a document that defines the Scope of the Project. It is especially important to be though and accurate because it feeds into the Requirements document. It is also important that all the Stakeholders buy into it. It should be signed off before going the next step. If the Scope changes it has to go through a change management process and all of the Stakeholders must sign off on it.

2.   Schedule Management Plan: The Schedule Management Plan is a component part of the Project Plan that is use in Activity resource planning. The Activity resource plan includes expert judgment, various levels of resource levels or skills, size of machines, tools and make/buy decisions.

3.   Cost Management Plan: Costs will adhere to a prescribed precision based on the scope of the project and may include a contingency amount. Various cost measures or other indicators (e.g. person-days, volume of product).

4.   Quality Management Plan: The Quality Management Plan describes how the project team will implement the organization’s quality policy. It must address the quality control, quality management and continuous process improvement for the project.

5.   Staffing Management Plan: Identifying project roles, responsibilities and reporting relationships. Obtaining the human resources to complete the project. Improving the competencies and interaction of team members to enhance project performance. Team building plays a big part here.

6.   Communications Plan: Determining the information needs of the stakeholders. Making needed communications available to the stakeholders in a timely manner. Collecting and distributing performance information including status reports, performance reports and forecasting.

7.   Risk Management Plan: The Risk Management Plan includes risk identification, risk analysis, risk response planning, monitoring and control.

8.   The Procurement Plan: This plan includes what has to be procured, who will provide the estimates, types of contracts to be used, managing multiple providers, constraints and assumptions that could affect the contract and handling make/buy decisions. [i]

---

[i] Guide to the Project Management Body of Knowledge (PMBOK@ Guide) Third Edition @2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

Team Building

Team Spirit is vital to the making of a team that works. It is the ability to work on ones’ own, feel free to ask for help and share the glory of your combined work. That is the reason why team communication and team building is so important.

When I first start a team, I have everyone take an assessment and share the results with each other. Everyone communicates differently and if you know the style of your team member it will go a long way in making that relationship successful. I also take the assessment and share it with the team. Pretty soon it gets to be fun when person A witnesses Person B reacting to Person C in a way that is uncomfortable for person C. If it is caught in the moment, people can laugh about it and not let it get in their way. Some teams I’ve worked on even go so far as wearing a badge that signifies their personality traits.

If a team is built with these suggestions in mind, they will work towards the goal of overall team success and not individual success. You may find a person or two who won’t follow this team building activity. If you run into this case, either remove the person from the team, or if this is not possible, give them a chance to see others make it work. People in general, want to do a good job and want their team to succeed.

On-going training for the team is essential and will keep the ideas fresh in their heads. It is also beneficial to have some bonding time like playing softball or some activity outside of work.

Another technique that is beneficial is to have a scoreboard that states how the team is doing towards making their goals. This should not be used to single out anyone, but to find areas where mentoring or training can help the overall team. Whenever the team beats its goals, the success should be celebrated. You’d be amazed how quickly the team will strive for high results.

There are two major types of teams: the ongoing team and the project team. We are going to concentrate on project teams since work that is of an ongoing nature is defined as an operation, not a project. The exception to this is in a matrix organization where the functional managers are in charge of the teams and loan them to the project manager for the duration of the project. IT team, the marketing-research team, and the accounts payable team.

Project teams are formed for a particular purpose; to complete the project. They usually disband when their mission is accomplished. The mission that binds them is the project’s mission and it falls upon the project manager to instill the leadership required to build followers of the project’s mission.

There are many benefits to be working on a project team.  The social aspects as well as the opportunities for less experienced members to learn from the more experienced members along with the abilities for the more experienced members to mentor and learn from that experience. The synergy that the team provides allows them to make better decisions than if they were working in isolation. Everyone has a different skill set to bring to the table. As we all have learned “the whole is larger than the sum of its parts”.

I’d like to say a little bit about team leaders. Some schools of thought are that the subject matter experts should be the team leaders. As I said before, everyone has a different skill set to bring to the table and most people who concentrate on becoming the expert in a particular technology are usually introverts and aren’t the one you want to resolve conflict between team members, keep the team on track and keep them energized. These folks usually are better at people skills, negotiations and are typically extroverts. That’s why having a mixture of talent makes up the best team. I once heard a Vice President talk to me about his staff. He said he always looked for people that were not like him, giving him a well rounded staff that came out with better solutions than a bunch of “Yes” men would have.

Another possibility is to train people to take over in leadership positions. The fact is you are born with natural abilities and you can be trained, but in a crisis situation will usually revert back to what you were born with. It is also a very unique individual who is good at everything required to run the business.

 

Effective Teams

I have often found that the key to any endeavor, including Project Management or Coaching, lies around building a good relationship. Think back to the most effective teams or relationships you have ever had. It should have characteristics such as:

 

·         Mutual trust should be a top priority

·         Honesty and integrity should also be up there

·         Confidentiality is important to a good team

·         You should make sure the team (and yourself) values differences

·         Teams should have a little fun

·         People like being respected (I once worked on a team where everyone was given a ping pong gun. If they caught anyone disrespecting another, they were allowed to shoot them)

·         The Goals must be clearly defined “SMART: goals. (S = specific, M= measureable, A = attainable, R = realistic and T = time based)

·         Responsibility that is expected in all the members of the team’s work – there is no such thing as “It’s not my job”

·         Shared responsibility, accountability and rewards tied to performance

·         frequent celebrations when called for

·         Ability to make decisions (the only way to learn is to take risks)

·         Mutual support and mentoring

·         AND the most important thing is a Leader who leads, sets a vision and allows sharing of ideas from all team members