Читать книгу Project Management For Dummies - Stanley E. Portny - Страница 55

We discussed the value you can realize by tailoring the models, methods, and artifacts that you use to manage your project. Now, let’s review some examples of those models, methods, and artifacts.

Models are frameworks, mindsets, and approaches for shaping project behavior or solving problems or otherwise satisfying some need. Many models exist solely in and for the project management realm, and other models come from more general methods or philosophies of human behavior, leadership, communication, and motivation. Most of these models could each fill up an entire chapter, or in many cases an entire book, so we won’t go into much detail here. You should take away from this section that there exists a model for nearly every situation, dynamic, personality, and yes, every project, and this is why it is important to tailor the model(s) you intend to use for your project and organization.

In lieu of a deep dive into each model, we cover some of the most used model types in project management:

 Situational leadership models are one type of leadership model that describes how you can tailor your leadership style to best suit your project team and team members. Situational leadership models, and leadership models in general, are inherently fluid and dynamic, as they offer a framework for responding to different and often changing situations and personalities.

 Effective communication is paramount to leading a successful project and communication models consider the different frames of reference of all parties to facilitate this effective communication. The sender of a message most likely brings with them a different perspective than the intended recipient of that message. The background, experiences, and culture of a recipient could notably impact how they receive, interpret, and react to a message. A critical element of communications, nowadays more than ever, is the channel through which that communication occurs. Whether you communicate face-to-face, by telephone, email, instant message, text message, blog, wiki, social media post, or old-fashioned smoke signals, your message could be received and interpreted differently than you intend.The most important consideration when choosing your mode of communication is whether it is situationally appropriate and likely to be interpreted by your recipient as intended. Beyond that, use whatever means of communication is easiest and most convenient for you and your team. In the end, if you’re able to reliably relay the meaning and tone of your message to the correct recipient who is similarly able to accurately receive and interpret it, you’ve chosen an effective communication model for your project.

 Your ability to motivate your team is arguably as important as how effectively you communicate with them. Motivation models address what drives people and how you can use that knowledge to your advantage. When you motivate, you create desirable outcomes that contribute to a mutually beneficial arrangement (your resource is motivated to achieve those desirable outcomes and, in doing so, provides a similarly desirable outcome for you and your project).People are often motivated by different factors. Where some are motivated at work by their ability to achieve, grow, and expand their knowledge base, others are motivated by salary, a corner office with a view, or an impressive job title. Where some are motivated by their ability to master a particular skill or to make a meaningful contribution to a larger team effort, others are motivated by their ability to define their own work hours, work from home when they prefer, or choose the projects to which they contribute. It doesn’t matter if you agree with what motivates another person – respect that what motivates them is unique and specific to them and find a way to deliver it so they will ultimately return the favor.

 Change models describe necessary activities to achieve successful change management. As with the model types discussed so far, there are many different change models, so let’s focus on some of the common and widely applicable characteristics. It is important to start with a sense of urgency to drive the need for change. Sir Isaac Newton’s First Law of Motion tells us that a body at rest tends to stay at rest, and a body in motion tends to stay in motion, unless acted upon by some outside force. This applies to human behavior as well. People typically gravitate toward a path that upholds the status quo unless you can provide them a compelling reason to change.Depending on your team dynamic, it can be helpful or even essential to form a coalition of influencers who have already accepted the need to change and can help bring other team members along for the ride. Change can often be a lengthy and arduous process, but this can largely be mitigated by creating near-term wins, often referred to as “low hanging fruit” or “quick hits.” While the metaphor of running a marathon is a bit overdone and even cliché at this point, it remains pertinent. For example, running the Boston marathon can be a daunting thought for even the most experienced and well-trained athletes. Breaking the course down into more “bite size” one-mile increments can be more manageable for some (and easy to track since there are mile markers and water stations at each mile). As you lead your team through difficult project tasks, keep in mind that, while it is important to keep your eye on the bigger picture, your team won’t last long enough to achieve the bigger picture if they lose their steam along the way.

 Project team development models help you assess your team’s maturity to empower you to further their growth and development throughout the project life cycle. Models of this type follow a similar framework: First, the team comes together; next, the team figures out who’s who and what’s what; next, the team finds their groove; finally, the team completes their mission and moves onto other projects. This is an intentionally oversimplified description because, as with many of the other types, these models are differentiated by their details and nuances. Some models focus more on interpersonal dynamics and development into a cohesive unit; others focus more on the team’s output and their ability to produce increasingly high-quality results as they become more accustomed to working together. Familiarize yourself with the project team development models described in PMBOK 7, specifically, and other literature, in general, so you are informed when you choose the aspects of each model that resonate as you build and nurture your teams.

Methods are means for achieving or producing an outcome or deliverable (see the description of artifacts later in this chapter for examples) and are typically categorized according to the purpose they serve or activity they help address, as follows:

 Data gathering and analysis: You are already familiar with several methods in this category, like the business case, cost-benefit analysis, feasibility study, and stakeholder analysis (part of creating the project charter covered earlier in this chapter). Data gathering and analysis methods help you collect, analyze, and evaluate facts and data to provide insight into a particular situation.

 Estimating: Some commonly used estimating methods include story point estimating in Agile Project Management (see Chapter 18 for more on Agile), affinity grouping (such as “T-shirt sizing”), and analogous estimating. Analogous estimating uses tasks and projects performed previously to inform estimates for similar tasks and projects to be performed. Generally, estimating methods facilitate your approximation of effort, duration, or cost.

 Meeting and events: You’re probably familiar, perhaps all too familiar, with the meetings you conduct throughout your projects. It is important to balance the need to engage and communicate with various stakeholder groups during a project with the risk of inducing “meeting fatigue” or “meeting overload” and detracting from the execution of the project work itself. That said, meetings and events are critical to project success, so let’s review some of the key ones that add value to nearly all projects:Kickoff meeting: Formally starts the project (or a specific phase of the project) and aligns the team and key stakeholders to the project’s goals and expectations.Standup meeting: A brief, usually 15 minute, daily session where you review progress from the prior day, review planned work for the current day, and call out any obstacles that might impede the team’s future progress. In Agile, this is called the “daily scrum.”Iteration/milestone/phase/Sprint review: This meeting is conducted once all the work for a specific phase of the project has been completed. Depending on the type of project, this review may include a demonstration and often culminates in a go/no-go decision to proceed to the next phase of the project.Status meeting: An opportunity to update stakeholders and review progress to date, status meetings are often accompanied by a status report, to indicate performance against budget, schedule, and milestones that may be reviewed with the attendees.Steering committee meeting: Comprised of senior-level stakeholders (from the client, your organization, and even vendors and contractors when appropriate) who provide direction and support to the project team and are empowered to make decisions outside of the project team’s authority.Project retrospective: Often referred to as a project post-mortem, a lessons learned meeting, or a project review and closeout meeting, a retrospective takes an objective look at all aspects of a recently completed project for two purposes: first, to ensure that mistakes or undesirable outcomes are understood so they can be avoided in the future; and second, to ensure that positive accomplishments of the project are called out, celebrated, and able to be repeated in future projects.

Artifacts are templates, outputs, or deliverables that result from one or more of the methods you just reviewed. Some projects require acutely specialized artifacts, relevant only to your industry, organization, or stakeholders. Many of the most often used artifacts are broadly applicable to most industries, organizations, and stakeholders. Many of these artifacts are explained in detail throughout this book, so we keep this list high-level for now.

 Strategy artifacts: Created prior to or at the onset of a project and referred to throughout the project to ensure they are satisfied by the project output. Examples include:Business case: See “Proposing a project in a business case” section earlier in this chapter for details.Project charter: See “Developing the Project Charter” section earlier in this chapter for details.Roadmap: A high-level timeline that shows milestones, key review and decision points, and is often subdivided into more manageable phases.

 Logs and registers: Ongoing records of continuously evolving factors. Examples include:Risk register: Risks, actions, issues, and decisions are often consolidated into a single log, called the RAID log. See the section “Preparing a Risk Management Plan” in Chapter 10 for more on risks.Issue log: The previous comment for risk register also applies to the issue log.Stakeholder register: More than just a contact list, this register classifies and assesses each stakeholder for the role they play in their organization and on the project. See Chapter 4 for more on this.

 Plans: Proposed means to achieve project goals. Examples include:Communications plan: Describes how, when, and by whom project communications will be disseminated. See Chapter 15 for more on this.Resource management plan: Explains how resources are identified, onboarded (or procured), supported (or maintained), and managed (or utilized) throughout the project. See Chapter 8 for more on human resource management (and Chapter 9 for non-personnel resource management).Risk management plan: Defines how risk will be triaged, classified, and addressed. See Chapter 10 for more on this.Change control plan: Presents the process to document, assess, and implement changes, whether they have a contractual or other impact to the project or not. See Chapter 14 for more on change control.

 Hierarchy charts: High-level info broken down into levels of increasingly greater detail. Examples include:Work breakdown structure (WBS): One of the most universally applicable and fundamental project management artifacts, the WBS decomposes the overall project scope into lower-level (and more detailed) tasks. Your goal should always be to define your WBS down to the most granular level of detail possible. See Chapter 14 for more on this.Organizational breakdown structure: Not to be confused with an “org chart,” this chart represents the relationship between tasks or activities and the organizational units assigned to them.

 Baselines: Approved plans against which progress is tracked to help identify and quantify variances. Examples include:Project schedule: Sometimes called a project plan and often presented in the form of or in conjunction with a Gantt chart, the project schedule illustrates linked tasks with planned dates, durations, milestones, and resource assignments. See Chapter 7 for more on this.Budget: The approved cost estimate for the project or component of your WBS. See Chapter 9 for more on this.

 Visual data and information: Charts, graphs, and diagrams to graphically present complex data in a visual manner that can be easier to digest and interpret. Examples include:Gantt chart: A graphical illustration of the project schedule that visually indicates task durations and dependencies throughout the project timeline. See Chapter 7 for more on this.Responsibility assignment matrix (RAM): One of the most common versions of a RAM is the RACI, which defines who is responsible, accountable, consulted, or informed for or about project activities, decisions, and deliverables. See Chapter 12 for more on this.Dashboards: Graphical representations of project metrics and KPIs that provide at-a-glance views of overall status. See Chapter 15 for more on this.

 Reports: Formal records of pertinent project information. Examples include:Status report: Usually includes progress made since last report, activities planned until the next report, budget and schedule status, risks and issues. See Chapter 15 for more on this.Quality report: Documents any quality management issues, corrective actions and recommendations for process, project, and product improvements to prevent similar quality issues from recurring.

 Agreements and contracts: Documentation of agreed-upon intentions and expectations between multiple parties. Examples include:Fixed-price contracts: These contracts define a deliverable and a price to be paid for that deliverable. As long as the project scope adheres to the contractually defined scope, the price does not change. Changes to scope are handled through change orders.Time and materials contracts: T&M contracts require each hour spent working on the project to be logged and invoiced to the client, including any materials or expenses required to satisfy the contract. These contracts often contain a not-to-exceed clause. This clause specifies the maximum number of hours to be invoiced to the client, assuming scope has not changed, before a new contract for any remaining or additional work is executed.Change orders: We all hope to be able to foresee every possible “gotcha” that could arise before our projects even begin but, alas, hope is never a winning strategy. When scope changes, change orders capture the nature of the change and any associated budget, schedule, or resource implications. See Chapter 14 for more on this.

 Other artifacts: Some artifacts don’t fit into one of the previous buckets, but are useful and add value, nonetheless. Examples include:Bid documents: Help to answer necessary questions to enable an informed procurement decision, including request for information (RFI), request for quotation (RFQ), and request for proposal (RFP).Requirements document: Depending on the type of project, this is often broken down further into a business requirements document, functional requirements document, and technical requirements document. See Chapter 5 for more on this.