Managing Variances

Managing the variance from your project baseline is sound PM practice. Here are tips to determine acceptable triple constraint variances (scope, time, and cost) for your project:

Examine your company’s behavior. Your business is likely to have common approaches for managing scope, time, and costs. Your project should conform to those norms for tolerating scope changes, schedule slippage, or budget overruns. While some businesses focus on maintaining a tight budget and schedule, others, due to intense competition in the marketplace, may focus on fulfilling scope, even if it means going over budget or behind schedule. In other business environments, schedule is critical. Government laws that go into effect on a certain date must have supporting systems and processes ready to go when a law is enacted.

Scheduled events will affect acceptable variance. Many businesses work on marketing release schedules, so products need to be ready for demonstration at key trade shows or other marketing events. Little to no schedule slippage is tolerable in these instances. There may be some tolerance for scope reduction however, if the product still meets market expectations.

Cost savings as a project outcome will affect your variance targets. There is likely to be little to no tolerance for budget overruns when cost savings is the project justification. However, if the cost savings come from improved processes or low-cost product production, scope may be the constraint where variances are unacceptable. Process changes that form the project scope may need to be unchanged to fulfill the cost savings objectives. In some cases, increasing the budget may be acceptable to ensure the long-term cost savings are achieved.

As you approach the end of your project, acceptable schedule variance tends to be tightened. This is because you have less time to recover from any delays. Budget constraints may tighten as well. If you are under budget, however, your ability to accept cost overruns for specific tasks may improve toward the end of your project. Be careful however – just because you are under budget doesn’t mean you can overspend on a given item – management may be counting on the excess allocated funds to apply to another project.

For more about managing variances, check out my Project Management Foundations course.

 

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

SMART Requirements are Agile

SMART guidelines are used to assess requirements in waterfall projects. They apply to agile projects as well:

Specific. In Agile, it doesn’t exist initially. Specific relates to the final product. Requirements are captured during development, not documented in advance. However, the end result typically goes beyond the detail and specificity of traditional requirements. When broad  requirements aren’t specific, they are typically broken down into several features in Agile, each of which provides specific functionality and can be more easily produced.

Measurable. The construction and evaluation of each feature focuses on measuring effectiveness. One of the most significant benefits of Agile is that performance and suitability measurement reviews are built into the development process. With a mindset towards prototyping, Agile features can be evaluated by users prior to implementation. When that cannot be done directly, for example, when a totally new business process is being created, the user-developer partnership used to build features in Agile reduces the risk of items failing to meet measurable business objectives.

Achievable. Feature sizing and prioritization ensures that achievability is regularly assessed. Features are examined for their integrity and ability to be produced during a sprint. Larger features are broken down into pieces that are more easily created, enhancing achievability. When the features can’t be broken down into manageable pieces, that’s a sign that they aren’t achievable. The developers and users can examine these features in real time to determine how critical they are and explore other ways to address the corresponding business need.

Realistic. In Agile, features are developed and accepted iteratively and in real time, versus weeks or months after requirements are documented in the traditional approach.  Agile lends itself to realistic outcomes and can accommodate the latest changes to business needs. The nature of Agile means the team learns about features and their capabilities more deeply, allowing users to make features more business-friendly. Feature capabilities have greater integrity and support better business processes.

Time-constrained. The sprint schedule is ideal for ensuring time constraints are placed on feature creation. In addition, there is the added value of being able to easily change timeframes when business priorities change. Reprioritization and re-stacking of features for each sprint provide an ongoing focus on development timeframes. While this time management approach isn’t perfect, features that require more time than anticipated to develop are re-evaluated and assigned to subsequent sprints as agreed by the Agile team.

 

For more about Agile, check out Doug Rose’s Agile Foundations course.

Why You Should Identify Risks Early

Identifying risks early in a project is a best practice. Here are some benefits of this great approach.

Obtain critical information for project approval.  Without identifying risks early, an inappropriate project could be launched, wasting money and valuable stakeholder time. Instead, understanding the risks provides a balanced view of the value of project outcomes. The expected outcomes could be prioritized or enhanced based on the risks presented by the project team, making the project more viable. Or the project could be deemed inappropriate due to those risks.

Make your initial plans more realistic.  Project overviews, including high-level plans, provide context that helps drive project approval. Those initial plans must consider project risks to be valid. With risks identified, the team can define mitigation actions and include them in the plans. Risk information helps the management team make go/no-go project decisions in the best interest of the business. In addition increasing the integrity of the approval decision, it also proactively sets key stakeholders’ expectations.

Set a reasonable project budget.  Risk management often requires additional funds to cover the costs of actions or contracts needed to manage risk. And these can be expensive. Considering these costs early in project planning helps the sponsor set a reasonable project budget with greater likelihood of meeting business expectations.

Determine early staffing requirements. Addressing risks typically includes staffing considerations. Expensive, contracted specialized skills could be required to manage technical risks.  Alternatively, you could make sure internal technical team leaders work on your project. (However, internal team leaders’ time may be limited, which can extend your project schedule.)

Capturing risks early in your project allows for better and more comprehensive decision-making. Because decisions are good and management is more informed when approving projects,the likelihood of implementing business goals and strategies successfully increases.

For more about risk management, check out Bob McGannon’s course Project Management Foundations: Risk.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

Staffing Your Project Team

Great project managers always seem the get the best people for their projects. What’s their secret? Establishing relationships with management works best:

You sell your project directly. With a good relationship, you can discuss in detail the benefits and drawbacks of the project as well as the development opportunities for having the manager’s employees work on your project. The manager also gets an opportunity to talk about specific objectives they have for their employee, which you can support via the task assignments and guidance you provide.

You can perform part of the managers’ work. Giving support and feedback to your team members along with periodic appraisals of their work as the project progresses is very useful to assigning manager. You can make their job easier, especially if you write performance evaluations in the context of the manager’s growth objectives for their employees. Managers who feel confident you do this well will work with you more readily when you seek project team members.

You can ask for a favor. If you need in-demand skills, a good relationship with assigning managers significantly increases the chances you’ll get the in-demand resources you need. Trust-based relationships make it easier for managers to take a risk and assign the most in-demand staff members to your project, even in instances where it is helpful but not necessary.

You can change resources more readily. If you have issues with a resource, the assigning manager is more likely to listen to you and support replacing your team member. At the very least, they are more likely to work with you to help improve your team member’s performance.

The team members you get make or break your projects. Getting to know the managers who assign employees to your projects is the best way to ensure you get the people you need to successfully deliver expected outcomes.

For more about working with team members, check out Chris Croft’s Managing Resources Across Project Teams course.

The Missing Charter Element: Sponsor Responsibilities

A project charter details the project manager’s responsibilities, but typically not the sponsor’s. Here’s why you should document sponsor responsibilities, too.

Identify who manages senior stakeholder relationships. Sometimes, senior project stakeholders don’t know the sponsor. For project success, key stakeholders need to understand and trust the sponsor and his or her motives.  The charter should define how those stakeholders will be engaged. For example, the responsibility could lie with the sponsor, a sponsorship committee, or it could be delegated to the project manager. By including high-level responsibility for stakeholder engagement in the charter, you can ensure that someone manages these crucial stakeholder relationships.

Identify how project funds are acquired. Sponsors may not have the authority to release project funds, even from their own budgets when expenses exceed a certain threshold. It’s important to understand and agree in advance on how project funds are released. You might need to work with financial managers to identify the process and specific data needed to release funds. To ensure that money is available when needed, in the project charter, document this information and process as part of the responsibilities of the sponsor and the financial managers.

Technical decisions may require consultation. Decisions regarding technical considerations may require expertise the sponsor doesn’t have. In that case, the sponsor would need to consult with technical managers to ensure the integrity of those decisions. The project charter can specify the sponsor’s and technical managers’ responsibilities revolving around those consultations.

Sponsor’s time constraints may require delegation to others. Sponsorship often falls to a high-level manager. While that gives them sweeping authority to make decisions, they might not have the time to execute all of their responsibilities. In that case, some sponsorship authority may be delegated to other managers. These delegations should be clearly stated in the project charter.  In addition, the sponsor’s level of time commitment to the project should be documented.  As a project manager, you need access to your sponsor or the sponsor’s delegates to ensure decisions can be made in a timely fashion.

For more about sponsorship, check out my Project Management Foundations course.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

Don’t ask for a project deadline

Project managers often ask for a project deadline. That might be a bad idea. Here are reasons to propose a project deadline rather than request one:

You need to analyze before agreeing to a deadline. Until your project team analyzes the work required to achieve business outcomes, you can’t be sure the deadline provided is feasible. Why ask for a deadline if you can’t acknowledge or refute? Instead, perform analysis on the requested scope and propose a defendable deadline. While that deadline may not be accepted without negotiation, you can talk knowledgeably about the specific risks of bringing in your proposed deadline.

Employ a proactive approach to project management. Setting arbitrary deadlines is not a recommended practice in business! Why do it with projects? Discussing possibilities, approaches and the capabilities and capacity of your team members is more constructive than building a case for why a project deadline may or may not be feasible. These discussions allow project managers to extend the capabilities and control organizational leaders have to manage the business.

Protect how your management team is perceived by team members.  Impractical, arbitrary deadlines proposed by managers can erode the trust-based relationship between management and your team members. Managers who propose deadlines without understanding the complexity of the work can be perceived as out of touch or unappreciative of the work teams perform. Defining objectives and deadlines using a consultative approach between the team and management instills trust and helps ensure buy-in.

Support early discussion of options for the business. Ask the project team for their opinions about business objectives. that way, you won’t have to defend impractical deadlines. Instead, the team can propose scope and time trade-offs and alternative solutions to achieve those business outcomes.

For more about project scheduling and deadlines, check out my Project Management Foundations course.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

Breaking down tasks for your WBS

A Work Breakdown Structure (WBS) breaks down your project into the activities needed to meet project objectives. Here are tips for breaking down project activities:

Break tasks down into 8 – 40 hours of effort.  To help track progress, break down work so tasks can be completed within a week. If a process takes longer than a week, establish checkpoints that are 40 hours of effort or less. Note: Toward the end of your project when you have less time to handle delayed task completions without impacting your project, shorten task durations to 16 hours or less so you can manage proactively.

Assign tasks to an individual, if possible. Every task will be assigned to people. Ideally, one person should be able to complete the broken-down task. When multiple people work on a task, name a spokesperson to track progress and report status. A best practice is to have an informal discussion with the spokesperson so you know how they will coordinate work on the task.

Identify how you tell when the task is complete.    To track progress easily, document what each low-level task delivers so you confirm that the task is complete.  As project manager, you don’t have to confirm completion. Ensure that a subject matter expert can confirm completion for every task in your WBS.

Tasks should be clearly defined.  Two main tests can be used to assess clarity: Will a team member assigned to work on the task understand the task description? Can you tell what tasks will precede or follow from a particular task? Tasks contribute to the construction of a schedule and should be defined logically, so you can determine whether a specific sequence is needed (i.e., you must write software before you test it). Alternatively, you might be able to perform tasks in parallel, like defining the task of “painting the house” to “paint the east side of the house” which could be done in parallel with “paint the west side of the house.”

For more about work breakdown structures, check out my Project Management Foundations: Schedules course.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

When to Create Customized Stakeholder Reports

reports

Reports

Standardized project communication is part of effective stakeholder management, and yet at times customized reports may be best. Here are tips for when to invest the additional effort to create customized reports:

A key stakeholder has unique priorities. Stakeholders have unique priorities. Often, customized reports are needed to address those priorities. For example, your finance director may be the only stakeholder interested in your project cash flow from month to month. A project report with specific spending details for your influential and engaged finance director may be appropriate to keep your project moving forward. Don’t volunteer to provide customized reports for every unique stakeholder priority, but be prepared to do so when required to secure stakeholder buy-in.

A risk mitigation strategy calls for customized reports. Awareness can be an effective risk mitigation response. For example, if staff shortages present a project risk, a customized report for the staffing coordinator to address planned versus actual staff hours would be a prudent risk response. Customized reporting can also identify risk triggers that signal a risk coming to fruition and invoke response strategies. While standard reports can usually do this, other reporting may be necessary to surface risk triggers to keep your project on track.

The project gets stuck. Information is usually step 1 for getting a bogged project going again. Customized reports for key stakeholders could be the catalyst for resetting your struggling project. For example, if your stakeholders have conflicting project objectives, customized reports that feature each stakeholder’s area of interest can maintain buy-in and get the project re-focused — or keep it from stalling in the first place.

A stakeholder is stuck.  Influential stakeholders may need to see data presented in a different format or require more detail before they give you their support. After trying to emphasize control capabilities using standard reports, consider alternative reporting to get the support of a critical stakeholder.

You need to reinforce a point. As project managers, we often have foresight to outcomes that busy stakeholders don’t see. Customized reports that demonstrate your concern can be effective in getting the support you need. Say a senior leader gives his staff a generic direction like “make time to work on this project.” As a project manager, you may know that staff is struggling with their everyday operational tasks and will have difficulty accomplishing project work. If your pleas to the senior leader for more detailed direction fall on deaf ears, a report that shows actual allocation of work to the project versus the senior leader’s expectation might demonstrate the need for more detailed prioritization from the leader.

For more about stakeholder management and communications, check out Doug Rose’s Project Management Foundations: Communication course.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

Photo by Bernd Klutsch on Unsplash

From Newbie to Know-it-all

technology expertI knew nothing about Project, QuickBooks, Visio, Basecamp and other tools when I started. I was a project manager and business owner faced with complicated tools I needed to do my jobs. Here are the techniques I use to master software quickly:

Take classes: Take more than one. Different teachers cover different topics and might provide great tips you haven’t heard anywhere else. Students learn in different ways – listening, watching, doing, and so on —  so it’s important to find an instructor who teaches in a way that resonates with you.

Read a book or two: If you’re really serious about mastering a product, get a book about it. Books can go into a lot more detail. Plus they have indexes to help you find topics and paper books are easy to flip through. eBooks are easy to search.

Read blogs about the product: Whether it’s the product blog or a blog from another organization, you can find incredibly helpful information there.

Search help: But don’t start in the in-product help. Use your browser and try different combinations of keywords or phrases. You’ll find results from product help but also from numerous other sites. Those other sites often have more detailed answers and great troubleshooting tips. Click the results that sound most like your question. If you don’t find an answer, click other results or try new keywords in your search. I have a very old HP LaserJet printer that works like a champ. I followed many links and eventually found info on the driver I needed to get the printer to work with Windows 10 – buried deep within HP help.

Post questions in product forums/groups: Product-related groups on LinkedIn, forums on the product website or forums hosted by other organizations have lots of knowledgeable people willing to share their expertise. You’re more likely to get helpful answers if you describe your issue in detail. Include the steps you took, what you expected, and what happened instead.

Explore on your own: Poke around the software. Try things. Test what happens when you perform different steps or use different software options. Use sample files to experiment. The more you do this, the better you’ll get at discovering things on your own.

Note: It’s tempting to immediately jump to asking an expert for an answer. That’s reasonable when you’re facing a tight deadline. However, you’ll learn and remember more when you expend some effort finding your answer.

Check out my courses on Linked In Learning here.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

#project, #quickbooks, #projectpointers, #bonniebiafore

 

Establish an Effective Project Approval Process

Delayed decisions by key project stakeholders can cripple a project schedule. Here are tips for managing your project approval processes to help you stay on track:

Determine the final arbiter: Although it’s best to get multiple opinions before project decisions are made, it’s crucial to clearly appoint the final arbiter for decisions. Collaboration is effective, but it can create undue delays if decision-making is not focused, and individuals can randomly enter objections or offer counter opinions. Set a timeframe for sharing viewpoints so reviews occur in a timely manner. Create tasks for decision-making in your project schedule with a deadline for final decisions.

Define targets for approval: Typically, project approval depends upon targets being reached, such as Return on Investment (ROI). Clearly define the targets required to gain project approval. In some instances, other project benefits might give you an opportunity to negotiate different targets. For example, while a project’s ROI might not reach a published target level, the project might qualify for approval if it significantly reduces business risk. Look at quantitative and qualitative benefits to make sure you generate the greatest opportunity for your project to be approved.

Understand the data required for approval:  In addition to defined targets, you must understand the data that’s required so you can ensure that it’s collected. To achieve project approval, be sure to summarize the collected data and present it in an intuitive, easy-to-understand manner. At times, some data may be deduced or estimated when included in a business case, and it can provide additional motivation for project approval.

Anticipate issues and conduct pre-approval meetings: A project should be approved only after relevant discussion. This is true for all project — even those that obviously need to be completed. Anticipating issues and conducting discussions prior to a formal approval meeting can streamline the process and save time. Also, what you learn from listening carefully during pre-approval conversations helps you define your project approach. In addition, you can obtain descriptions of your project outcomes in terms that are meaningful to your key stakeholders.

For more about project justification, check out my LinkedIn Learning course Project Management Foundations.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.