They depend on communication, decision making, and combinations of creative and logical thought. Projects usually involve a schedule, a budget, and a customer. Most importantly, the central task of projects is to combine the works of different people into a singular, coherent whole that will be useful to people or customers. I studied other fields to see how they solved the central challenges to their projects.
I wondered how projects like the Hubble Space Telescope and the Boeing were designed and constructed. Could I reuse anything from their complex specifications and planning processes? Or when the Chrysler Building was built in New York City and the Parthenon in Athens, did the project leaders plan and estimate their construction in the same way my programmers did?
What were the interesting differences, and what can be gained by examining those differences? How about newspaper editors, who organize and plan for daily production of information? They were doing multimedia pictures and words long before the first dreams of web publishing. What about feature film production? The Apollo 13 launch? By examining these questions, I was able to look at how I went about leading project teams in a new way.
But I do know that when I returned to the software world after looking elsewhere, my own processes and tools looked different to me. On the whole, I realized that many of the useful approaches and comparisons I found were never mentioned during my computer science studies in college.
They were never discussed at tech-sector conferences or written about in trade magazines. The key lessons from my inquiries into the past are the following three points:. Project management and software development are not sacred arts. Any modern engineering work is one new entry in the long history of making things. The technologies and skills may change, but many of the core challenges that make engineering difficult remain.
All things, whether programming languages or development methodologies, are unique in some ways but derivative in others. The simpler your view of what you do, the more power and focus you will have in doing it. If we keep a simple view of our work, we can find useful comparisons to other ways to make things that exist all around us. There will be more examples and lessons from history and modern industries that can be pulled from, compared with, and contrasted against.
Staying curious and open is what makes growth possible, and it requires practice to maintain that mindset. To keep learning, we have to avoid the temptation to slide into narrow, safe views of what we do. The best athletes, writers, programmers, and managers tend to be the ones who always see what they do as simple in nature but simultaneously difficult. Remember that simple is not the same thing as easy. What could be simpler? Leadership and management are also difficult, but their nature—getting things done in a specific way toward a specific goal—is simple.
One simple question that arises in studying the history of projects is this: why would anyone willingly suffer through mistakes and disappointments if they could be avoided? If the history of both ancient and modern engineering is public, and we get paid for doing smart things regardless of where the inspiration came from, why do so few organizations reward people for harvesting lessons from the past?
As projects are completed or are canceled and many development projects end this way [ 2 ] every day, little is done to learn from what happened. It seems that managers in most organizations rarely reward people for seeking out this kind of knowledge.
In part, this happens because failures force us to pay attention. As Karl Popper [ 3 ] suggested, there are only two kinds of theories: those that are wrong and those that are incomplete. Without failure, we forget, in arrogance, that our understanding of things is never as complete as we think it is. We should use their experiences to leverage against the future. While the superficial details of failure might differ dramatically from project to project, the root causes or team actions that led to them might be entirely transferable and avoidable.
Even on our own projects, we need to avoid the habit of running away and hiding from failures. Instead, we should see them as opportunities to learn something. What factors contributed to it happening? Which ones might be easy to minimize or eliminate? According to Petroski, real knowledge from real failure is the most powerful source of progress we have, provided we have the courage to carefully examine what happened. Perhaps this is why The Boeing Company, one of the largest airplane design and engineering firms in the world, keeps a black book of lessons it has learned from design and engineering failures.
Any organization that manages to do this not only increases its chances for successful projects, but also helps create an environment that can discuss and confront failure openly, instead of denying and hiding from it. It seems that software developers need to keep black books of their own. It can be hard to apply lessons across decades and sustain empathy for things that seem so different from how work is done today.
One alternative is to make comparisons with interesting kinds of modern projects. Often, seeing things firsthand is the only way to give people enough information to make connections among diverse ideas. As an example, I know a web developer who believes that his work is unlike anything else in the history of the universe. He feels that because web development requires him to make complex engineering decisions—designing and coordinating as he goes, verifying changes in a matter of hours or even minutes, and then publishing it all to the world—his project and task management is unlike anything ever seen before.
Or perhaps you have worked in situations where it seemed improbable that anyone else in the universe ever managed anything as complex as what you were doing. I suggested to this developer friend that he wander into the back of his favorite lunch establishment on a busy day. Cooks are often juggling frying pans with different orders at different states of completion, and scrambling between multiple sets of burners in opposite corners of the kitchen, while waiters run in and out, delivering news of new adjustments and problems from customers.
All of this happens in small, cramped rooms, well over 90 degrees, with bright fluorescent lights glaring above.
And despite how many orders go out every few seconds, new ones come in just as fast. Sometimes orders get sent back, or, much like software projects, require custom and last-minute modifications table 1 is lactose intolerant; table 2 needs the sauce on the side, etc.
Large, busy kitchens are amazing to watch. As chaotic as they may seem at first, great kitchens run with a level of intensity and precision that blows most development teams away. Working chefs and line cooks are culinary project managers, or as Bourdain refers to them, air traffic controllers another profession for the introspective to consider. He might not let you, but if he does, you will not be disappointed.
Some trendier restaurants and bars have open kitchens. If you find one, sit as close to the kitchen as you can. Then follow one person for a few minutes. Watch how orders are placed, tracked, constructed, and delivered. Another interesting field lesson in project management comes from hospital emergency rooms. The medical environment, especially trauma situations, offers a fascinating comparison for team-based work, high-stress decision making, and project outcomes that affect many people every day see Figure for a rough comparison of this and other work environments.
We look for medicine to be an orderly field of knowledge and procedure. But it is not. It is an imperfect science, an enterprise of constantly changing knowledge, uncertain information, fallible individuals, and at the same time lives on the line. There is science in what we do, yes, but also habit, intuition, and sometimes plain old guessing.
The gap between what we know and we aim for persists. And this gap complicates everything we do. Fred Brooks, in the classic book on software engineering, The Mythical Man-Month Addison-Wesley Professional, , makes similar comparisons between teams of surgeons and teams of programmers. Even though lives are rarely at stake when working on web sites or databases, there are many valid similarities in the challenges these different teams of people must face.
Project management can be a profession, a job, a role, or an activity. Some companies have project managers whose job is to oversee entire person projects. Others use the title for line-level junior managers, each responsible for a small area of a large project. By project management activity I mean leading the team in figuring out what the project is planning, scheduling, and requirements gathering , shepherding the project through design and development work communication, decision making, and mid-game strategy , and driving the project through to completion leadership, crisis management, and end-game strategy.
This book is less about job titles and formalizations, and more about how to get things done and make things happen. Sometimes the absence of a dedicated project manager works fine. Programmers and their bosses maintain schedules and engineering plans if any , and a business analyst or marketing person does the planning or requirements work. Anything else that might qualify as project management simply gets distributed across the team.
Perhaps people on the team have been hired for their interest beyond writing code. They might not mind early planning, user interface design, or business strategy. There can be significant optimizations in working this way. Efficiency and simplicity are good things. But other times, the absence of a project manager creates dysfunction.
Without a person whose primary job is to shepherd the overall effort, individual biases and interests can derail the directions of the team. Strong adversarial factions may develop around engineering and business roles, slowing progress and frustrating everyone involved. Consider that in hospital emergency rooms, one doctor takes the lead in deciding the course of action for a patient.
This expedites many decisions and gives clarity to the roles that everyone on the trauma team is expected to play. Without that kind of clear authority for project management-type issues, development teams can run into trouble. If there is no clear owner for leading bug triage, or no one is dedicated to tracking the schedule and flagging problems, those tasks might lag dangerously behind individual, programming-centric activities. While I think many of the best programmers understand enough about project management to do it themselves, they also recognize the unique value of a good, dedicated person playing the role of manager.
Microsoft had a problem in the late s regarding how to coordinate engineering efforts with the marketing and business side of each division some might say this is still a problem for Microsoft and many other companies. A wise man named Jabe Blumenthal realized that there could be a special job where an individual would be involved with these two functions, playing a role of both leadership and coordination.
Project quality focuses on the end product or service deliverables that reflect the purpose of the project. The project manager is responsible for developing a project execution approach that provides for a clear understanding of the expected project deliverables and the quality specifications. The project manager of a housing construction project not only needs to understand which rooms in the house will be carpeted but also what grade of carpet is needed.
A room with a high volume of traffic will need a high-grade carpet. The project manager is responsible for developing a project quality plan that defines the quality expectations and ensures that the specifications and expectations are met.
Developing a good understanding of the project deliverables through documenting specifications and expectations is critical to a good quality plan. The processes for ensuring that the specifications and expectations are met are integrated into the project execution plan.
Just as the project budget and completion dates may change over the life of a project, the project specifications may also change. Changes in quality specifications are typically managed in the same process as cost or schedule changes. The impact of the changes is analyzed for impact on cost and schedule, and with appropriate approvals, changes are made to the project execution plan.
The material found in this chapter would be similar to material found in a good operational management text. Although any of the quality management techniques designed to make incremental improvement to work processes can be applied to a project work process, the character of a project unique and relatively short in duration makes small improvements less attractive on projects.
Rework on projects, as with manufacturing operations, increases the cost of the product or service and often increases the time needed to complete the reworked activities. Because of the duration constraints of a project, the development of the appropriate skills, materials, and work processes early in the project is critical to project success.
On more complex projects, time is allocated to developing a plan to understand and develop the appropriate levels of skills and work processes. Project management organizations that execute several similar types of projects may find process improvement tools useful in identifying and improving the baseline processes used on their projects.
Process improvement tools may also be helpful in identifying cost and schedule improvement opportunities. Opportunities for improvement must be found quickly to influence project performance. The investment in time and resources to find improvements is greatest during the early stages of the project, when the project is in the planning stages. During later project stages, as pressures to meet project schedule goals increase, the culture of the project is less conducive to making changes in work processes.
Another opportunity for applying process improvement tools is on projects that have repetitive processes. A housing contractor that is building several identical houses may benefit from evaluating work processes in the first few houses to explore the opportunities available to improve the work processes. Staffing the project with the right skills, at the right place, and at the right time is an important responsibility of the project management team. The project usually has two types of team members: functional managers and process managers.
The functional managers and team focus on the technology of the project. On a construction project, the functional managers would include the engineering manager and construction superintendents. On a training project, the functional manager would include the professional trainers; on an information technology project, the software development managers would be functional managers. The project management team also includes project process managers. The project controls team would include process managers who have expertise in estimating, cost tracking, planning, and scheduling.
The project manager needs functional and process expertise to plan and execute a successful project. Because projects are temporary, the staffing plan for a project typically reflects both the long-term goals of skilled team members needed for the project and short-term commitment that reflects the nature of the project.
Exact start and end dates for team members are often negotiated to best meet the needs of individuals and the project.
The staffing plan is also determined by the different phases of the project. Team members needed in the early or conceptual phases of the project are often not needed during the later phases or project closeout phases. Team members needed during the implementation phase are often not needed during the conceptual or closeout phases. Each phase has staffing requirements, and the staffing of a complex project requires detailed planning to have the right skills, at the right place, at the right time.
Typically a core project management team is dedicated to the project from start-up to closeout. This core team would include members of the project management team: project manager, project controls, project procurement, and key members of the function management or experts in the technology of the project.
Although longer projects may experience more team turnover than shorter projects, it is important on all projects to have team members who can provide continuity through the project phases. For example, on a large commercial building project, the civil engineering team that designs the site work where the building will be constructed would make their largest contribution during the early phases of the design.
The civil engineering lead would bring on different civil engineering specialties as they were needed. As the civil engineering work is completed and the structural engineering is well underway, a large portion of the civil engineers would be released from the project.
The functional managers, the engineering manager, and civil engineering lead would provide expertise during the entire length of the project, addressing technical questions that may arise and addressing change requests. Project team members can be assigned to the project from a number of different sources.
The organization that charters the project can assign talented managers and staff from functional units within the organization, contract with individuals or agencies to staff positions on the project, temporarily hire staff for the project, or use any combination of these staffing options.
This staffing approach allows the project manager to create the project organizational culture. Some project cultures are more structured and detail oriented, and some are less structured with less formal roles and communication requirements. The type of culture the project manager creates depends greatly on the type of project. Completing a complex project successfully requires teamwork, and teamwork requires good communication among team members. Teams that use electronic methods of communicating without face-to-face meetings are called virtual teams.
Communicating can be divided into two categories: synchronous and asynchronous. If all the parties to the communication are taking part in the exchange at the same time, the communication is synchronous. A telephone conference call is an example of synchronous communication.
When the participants are not interacting at the same time, the communication is asynchronous. The letter a at the beginning of the word means not. Communications technologies require a variety of compatible devices, software, and service providers, and communication with a global virtual team can involve many different time zones.
Establishing effective communications requires a communications plan. Risk exists on all projects. The role of the project management team is to understand the kinds and levels of risks on the project and then to develop and implement plans to mitigate these risks. Risk represents the likelihood that an event will happen during the life of the project that will negatively affect the achievement of project goals.
The type and amount of risk varies by industry type, complexity, and phase of the project. The project risk plan will also reflect the risk profile of the project manager and key stakeholders. People have different comfort levels with risk, and some members of the project team will be more risk averse than others. The first step in developing a risk management plan involves identifying potential project risks.
Some risks are easy to identify, such as the potential for a damaging storm in the Caribbean, and some are less obvious.
Many industries or companies have risk checklists developed from past experience. The Construction Industry Institute published a item risk checklist that provides examples and areas of project risks. No risk checklist will include all potential risks. The value of a checklist is the stimulation of discussion and thought about the potential risks on a project. The project team analyzes the identified risks and estimates the likelihood of the risks occurring.
The team then estimates the potential impact on project goals if the event does occur. The outcome from this process is a prioritized list of estimated project risks with a value that represents the likelihood of occurrence and the potential impact on the project.
The project team then develops a risk mitigation plan that reduces the likelihood of an event occurring or reduces the impact on the project if the event does occur. The risk management plan is integrated into the project execution plan, and mitigation activities are assigned to the appropriate project team member. The likelihood that all the potential events identified in the risk analysis would occur is extremely rare.
The likelihood that one or more events will happen is high. The project risk plan reflects the risk profile of the project and balances the investment of the mitigation against the benefit for the project. One of the more common risk mitigation approaches is the use of contingency. Contingency is funds set aside by the project team to address unforeseen events. Projects with a high-risk profile will typically have a large contingency budget.
If the team knows which activities have the highest risk, contingency can be allocated to activities with the highest risk. When risks are less identifiable to specific activities, contingency is identified in a separate line item.
The plan includes periodic risk-plan reviews during the life of the project. The risk review evaluates the effectiveness of the current plan and explores possible risks not identified in earlier sessions. The procurement effort on projects varies widely and depends on the type of project. Often the client organization will provide procurement services on less complex projects. In this case, the project team identifies the materials, equipment, and supplies needed by the project and provides product specifications and a detailed delivery schedule.
While experience remains the most important indicator of a capable project manager, those wishing to work on government projects will need formal training and certifications. I think that Zucker summed it up best when he reflected back on his years as a project manager, and contemplated the future of the industry:. I was initially attracted to project management because you could see the tangible fruits of your labors—a completed and hopefully successful project.
Over the years, the processes and techniques have changed some. But project management is still a dynamic and fascinating profession… it is great to be part of industry that is always striving for more. Change can be scary. The future can be scary.
Are you a veteran project manager? And, based on your experience, what changes do you anticipate coming to the industry over the next 30 years. Senior Content Writer Capterra, sharing insights about retail. Austin transplant. I love spending time outside with my dog or floating on the Colorado River in my inflatable kayak. Helping businesses choose better software since About Us FAQs.
Log in. Sign up. Software Categories. Who We Are. For Vendors Write a Review. Project management is all about change. The history of project management through the ages While you could argue that project management concepts were used during the construction of ancient wonders like the Egyptian Pyramids and the Great Wall of China, modern project management really started to take shape in the early s with the development of Gantt charts.
The good old days of project management. Interested in leveraging agile project management tools? Looking for Project Management software? Check out Capterra's list of the best Project Management software solutions. Tags: project management. About the Author. Comments No comments yet. Be the first! Comment Guidelines: All comments are moderated before publication and must meet our guidelines. Comments must be substantive, professional, and avoid self promotion. Moderators use discretion when approving comments.
Your privacy is important to us. Check out our Privacy Policy.
0コメント