The Power of Out of Scope

/in /by

The most important section of the scope statement may be what’s out of scope. By discussing what’s out of scope, the project manager and stakeholders can refine their perception of the project’s purpose and how it will improve the business. This allows the project manager to focus the project team, and stakeholders who try to expand project scope. The out of scope section:

Demonstrates priority. Being specific about what is in and out of scope helps you get the best value by concentrating on the most impactful business outcomes.

Reduces scope. A smaller scope allows for more focused effort, a smaller team to manage, and less need for integration. These significantly reduce complexity and increase the probability of successful project completion.

Creates early debate. Proposing what is out of scope inspires senior stakeholders to express their views and discuss needed outcomes. These discussions ensure stakeholder support of the project scope and avoid delays later.

Reduces time and cost. Restricting scope reduces the overall project effort, reducing the cost and time to deliver project outcomes. Productive discussions about out of scope items can also help reduce scope if schedule or cost constraints surface as the project progresses.

When might you start a project without a business case?

/in /by

While I was in Australia, Bob McGannon and I talked about when, if ever, you would start a project without a business case. It was a fun discussion. Click here to watch!

Alexandria Bay

Can something be too small to need project management techniques?

/in /by

I spent some time in Australia with my good friend and project manager/LinkedIn Learning author extraordinaire, Bob McGannon. We talked about several interesting questions in the project management and leadership domain. Check out the video of our discussion!

How long can I live with project assumptions?

/in /by

How long should you proceed with your project without validating assumptions?

Assumptions about a product’s or idea’s marketability should be validated quickly. Money spent on a product with unvalidated marketability is at risk. Share product specifications, drawings, or a mock-up built with Legos, but produce a prototype to validate your product’s marketability.

Key stakeholder assumptions about funding or staffing should also be validated quickly. Get with your stakeholders early and convert assumptions into commitments.

Assumptions about the availability or capability of a product you need are sometimes critical to confirm, sometimes not. If the product is unique, confirm your assumption ASAP. If there are alternatives, the assumption can probably wait.

Assumptions about government legislation, licensing or approvals can be tricky.Often, they’re a make or break proposition for your project. Unfortunately, you only know what you’re dealing with after the government passes a law (or not) or grants a license. Plan your project around these approval events, and weigh the risks of working before you fully understand the government’s decision.

Assumptions about data being available to support your project is important to resolve early. For example, you might obtain a new software system that depends on critical data to operate properly. Purchasing that system before validating that the required data is available is VERY high risk. Determine how to obtain and determine the accuracy of that data as soon as possible.

Project assumptions can be broad and varied. What inaccurate assumptions have you heard about that created issues? Share those in the comments section so we can all learn together!

What should you do if you don’t agree with the project business case?

/1 Comment/in /by

The answer depends on what makes you uncomfortable.

The project business case forms the basis of the project. Get it wrong and the likelihood of a successful project is low.

If you believe the business case data lacks integrity, discuss this with your sponsor immediately. Contrast your information with what’s in the business case and work through the differences. The business case sets expectations, so you’ll eventually need to compare project outcomes against the business case. Don’t wait until the end of the project to challenge the business case. Take action now!

If you’re concerned with risk in the business case, seek to understand your sponsor’s risk profile. As a project manager, part of your role is to ensure your sponsor and key stakeholders understand the project risks. Your role is NOT to ensure risk goes away, When you’re concerned with business case risk, point out the risks to stakeholders and establish response plans. When you understand the risks your sponsor is comfortable and uncomfortable with, you can perform risk management effectively.

If the business case was not built collaboratively, review the business case with key stakeholders. They usually focus on their own interests and perceptions of risk and may be uncomfortable with the business case or its approaches. Discussions to analyze and align the business case with key stakeholders are critical. Moving forward with a business case that hasn’t been reviewed and agreed upon makes it difficult to get staffing and decision-making support.

Proactively addressing issues in the business case will help you deliver your project successfully as well as establish your authority with project stakeholders.

What if the sponsor doesn’t want a feasibility study – they want a 100% guarantee!!!

/in /by

Projects are risky by definition! You are trying to create something that has never been created before. Some executives find this uncomfortable and request a feasibility study to determine whether the project is viable. It’s a smart thing to do: it helps you build a good initial scope statement and project charter. However, if the feasibility study is supposed to create certainty about the project outcome – meaning no risk – you’ve got a problem. Here are some tips if you find yourself in this situation.

  1. Focus on creating a risk plan and sharing it enthusiastically. This may seem a bit counter-intuitive. You have executives who don’t want risk, and the advice is to shove a risk plan in their face! The fundamental truth is that projects involve risk. Embrace that! Presenting a methodical way to approach risk is the best way to balance the reality of those risks with a sense of control.
  2.  Package your project approach as a story. When your executive sees how the project can come to pass via a believable story, you can ease their fears and allow a reasonable project to move forward.
  3.  Focus on the steps in your plans and how you can validate each step as they occur. Executives often fear that they will lose control and incur large expenses or delays. Building sound plans and project controls can ease your executives’ anxiety. Make your sponsor comfortable that they will have control over the project and can act proactively if things go sideways. Doing so will put your sponsor, yourself and your organization in a much better position to deliver a viable project.
  4. Understand your sponsor’s greatest concerns and communicate status about those concerns. If they are concerned about spending, create as detailed a budget and spending plan as you can and review status regularly. When the status isn’t good, report it quickly  — along with actions that can be taken. Ensure a sense of control and understanding is present regarding your project, and you and your sponsor are more likely to work together to produce great project outcomes.

Top 5 Project Management Skills You Never Knew You Needed

/in /by

As a project manager no two days are the same. Business changes, project dynamics, and the myriad stakeholders you deal with are just the beginning. For daily entertainment, here are a few additional project management skills you must develop and deploy to be effective:

  1. Storyteller – Effective conversations and project documentation are the beginning of your project story. What you really need is vivid communication–the story of how your project can progress from idea to reality. Senior leaders need reassurance, often in the form of hero reports and processes that save the day. Practice telling the story of your project. To be certain your story will sell your senior leaders, make it part Marvel action movie and part warm snuggly lullaby. Do that, and you’ll be in your project’s driver’s seat.
  2. Non-insulting Consultant – One of the more challenging things a project manager does is turn away work. That’s right – you have to say no to some project assignments. Pet projects, impractical projects that sponsors erroneously assume employees will buy into, and other unrealistic project concepts will cross your desk for justification. When you find yourself in this position, you need to put on your consulting hat and convince your enthusiastic sponsor their idea won’t fly. You have to be firm and direct and, at the same time, avoid insulting them. Take the approach of steward of your sponsor’s business and assure them that your job is to protect them from issues that impact the bottom line. Consider telling a good project horror story (see item 1).
  3. The Battle-revealer and Peacemaker – Your project sponsor may be totally convinced about a project, while other key stakeholders think differently. Finding those not-so-on-board stakeholders and revealing the battle that needs to be fought is critical for success. Otherwise, you’ll have one significant stakeholder tell you to go north while another tells you to go south. Good luck with THAT! Find the requirement and prioritization mismatches, get the combatants in a room, and help them clearly articulate their differences. You act as the peacemaker and look for compromise, if necessary. Then your life as project manager will be much easier.
  4. The Discoverer of wobbly truth – The people you need to work on your projects are almost always working on other things, too. (If you run a project with 100% dedicated resources, you haven’t experienced the full fun of being a PM!) Your project team members are juggling things and almost always underestimate. They try to be diligent, but they’re usually optimistic about what they can produce, in quantity and quality. Gently and compassionately, you need to find the truth about what your project team can produce and the status of their work. Wobbly truth (a well-intended statement that isn’t a lie, but doesn’t turn out to be accurate) has spawned more nightmares than Dracula—at least for project managers. Be persistent and kind, but don’t stop poking until you get the truth.
  5. Executive Whisperer – Anticipating your sponsor’s reactions to project twists and turns is a useful skill. Even more important is understanding the fears that these project situations will awaken in your senior leaders. Understanding those fears helps you identify the information to share to either reassure them or give them clear options to help you address the concern. Executive whispering is best performed going into a project, when you can have a conversation with your sponsor and other stakeholders about the risks they are most concerned about and the positive outcomes they value most. That way, you can whisper to your senior leaders to help you guide the project and control their fears!

Tips for Managing Small Projects

/in /by

When managing small projects, less is more. A small project needs to be a lean machine, and unnecessary work and inefficiency gum up the works. Here are five tips to make your small projects run more smoothly.

Tip #1: Small projects often have tight budgets and short durations. There’s no room for unnecessary steps or nice-to-have deliverables.

Hash out what the customer really wants (project scope) – and put it in writing. Don’t forget to document what isn’t in scope. Say you’re building a web site for your customer. In a meeting with the customer, you develop the following scope:

Scope

  • Choose web tools, templates, and add-ons based on customer requirements for online sales and contact options.
  • Design, prototype, and build a 3-page website: home page, purchasing page, and contact page.
  • Two rounds of edits during design phase.
  • One round of edits during development.
  • Test website.

Out of scope

  • Design changes after acceptance of design will be handled as change requests. Changes after the first round of development edits will be handled as change requests.
  • Customer purchases web tools, add-ons, and hosting.
  • Customer resources perform review and acceptance testing.

After you nail down scope, be sure to balance the project triple constraints (scope, time, and budget). Are the desired timeframe and budget realistic relative to the project scope? If not, work with the customer to identify an acceptable compromise: maintain scope and increase the time or budget, trim the scope, or some other combination.

Tip #2: Do just enough to make the project a success.

This tip might sound contra-intuitive, but your goal as project manager is to complete the project successfully. That means delivering what the project is supposed to – not to exceed expectations. Make sure your team works on just the work that’s required and don’t address other objectives or nice-to-have deliverables.

Tip #3: Build an effective team and keep it that way.

If you have a choice, use people who know how to do the kind of work the project requires, and ideally who have worked well together in the past. Good teamwork is important. People who work well together might get more done, even if they are a little less experienced.

Make sure your team knows what to do and help clear the way, so they can get their work done.Keep your team members motivated. Help them understand how they contribute to project success and make them feel appreciated.

Tip #4: Keep things simple.

Time, money, and resources can be hard to come by on small projects. Don’t squander them by over-complicating things. Use simple processes and procedures for tracking time, managing changes, communicating, and so on. Ask for only the information you need to manage the project and hold only the meetings that are necessary.

Tip #5: Keep things organized.

You can’t afford to waste time looking for information, performing work that someone else already finished, or redoing work because the instructions weren’t complete or clear.Good organization also helps everyone else find what they need.Store project information where it’s easy to get to by everyone who needs it.

For more tips on managing small projects, check out my updated course, Project Management Foundations: Managing Small Projects.

 

Analyzing Profit and Loss with QuickBooks Classes

/in /by

QuickBooks classes are ideal when you need to analyze finances across accounts, income, expenses, customers, jobs, vendors. Classes help you track financial results by categories such as business unit, location, partner, or item. Classes can span time and items, too, because you assign a class to individual transactions (such as checks, bills, sales receipts, and invoices) as well as to specific line items on invoices or bills.

Read more

Choosing the Right Dependency Between Project Activities

/in , , /by

The schedule logic for a project is the collection of dependencies you create between activities. The goal of this schedule logic is to provide a realistic model of when project activities should occur. Want to up your scheduling game? This article explains when to use each dependency type to link activities.

Finish-to-start is the one you’ll use most often. A finish-to-start dependency tells you that when one activity (called the predecessor) finishes, the next activity (the successor) can start. For example, you have to finish writing some code before you can test it. If you don’t work in software, maybe this example will resonate: when your older child teases the younger one, the younger one starts crying.

On the other hand, the start-to-finish dependency type is rare (which is a gift because it’s also confusing). This dependency means that the start of one activity determines when another one finishes. It’s confusing because the predecessor occurs later than the successor, as shown in the figure, and most people think of predecessors occurring before successors. (Remember, with dependencies, the predecessor is the activity that controls the timing of the successor, not when it occurs time-wise.) For example, consider a sales clerk who works a shift in a retail store. To keep the store open for customers, the clerk for the next shift has to show up to start his or her shift before the sales clerk on duty can go home (finish the shift).

Let’s look at the remaining two dependency types: start-to-start and finish-to-finish.

Suppose one person is scheduled to spend 10 days writing software documentation and another one is scheduled to work 10 days reviewing the documentation to make sure it’s accurate and clear. At first glance, you might think start-to-start and finish-to-finish dependencies work equally well. When the writing starts, the review could start almost immediately. Or, when the writing is complete, the review could finish soon after.

But start-to-start dependencies can cause trouble if activities don’t occur as scheduled. Suppose the writer runs into issues with the software and the writing task is going to take 15 days instead of 10. As you can see in the figure, the writing and review started at the same time, which means that the review is scheduled to finish 5 days before the writing. Some of the writing wouldn’t get reviewed unless you caught this error in your schedule logic.

The writing and review activities should be linked with a finish-to-finish dependency. That way, the schedule logic guarantees that the review doesn’t finish until the writing is complete, even if the writing takes longer. This dependency also works if the review takes less time than writing—say, 5 days. With finish-to-finish, you could wait 5 days before starting to review documentation, as shown in the figure below. If the writing takes longer than you expect, the delayed finish date for writing also delays the finish for review.

As you can see, almost all your dependencies will be finish-to-start or finish-to-finish. Another dependency best practice is to avoid negative lag (also called lead), because it implies that you know when the predecessor activity will finish. (You can explore this practice in this movie from my revamped and updated course, Project Management Foundations: Scheduling, which was released in April 2018).