Author: Andy Makar

Andy Makar

About Andy Makar

Dr. Andrew Makar is an IT program manager and is the author of Project Management Interview Questions Made Easy. For more project management advice, visit the website Tactical Project Management.

Mentoring My Younger Self (with a Little Help from Back to the Future)

| Comment
Advice Commentary Featured Tips

If you knew then what you know now, I’m sure you’d make all the right decisions. If I had a time-traveling DeLorean, I could advise my younger self and avoid all those project management mishaps. Assuming Marty McFly pulled up in my driveway with a fully charged flux capacitor, here are a few key lessons I wish my younger self would’ve known before starting my project management career.

Lesson 1: Don’t take it all on yourself; leverage the team.

Despite all the upfront resource planning, projects still have resource gaps. If a business analyst needs help gathering requirements or if end users need help conducting user acceptance testing, the project manager is usually the one that fills the gap.

The project manager is the Swiss Army knife of superheroes, dedicated to ensuring project success. Despite the superhero mantle, being the PM doesn’t mean you have to take on all the project work yourself. Your job is to get the right resources to ensure your project will be successful. If you don’t have enough people, you need to raise the issue early and often and communicate the impacts.

I’ve played the superhero enough times to realize I can’t solve every project issue. I would tell my younger self to leverage the team to solve project problems as each team member provides a different perspective and solution.

Lesson 2: Listen more; lead later.

The Greek philosopher Epictetus said, “You were born with two ears and one mouth for a reason.” If you get a team of project managers in a room, you’ll witness a lot more talking than effective listening.

As a project manager, you have a desire to lead, achieve deliverables, and demonstrate progress. You have an inherent drive for results-leadership behavior. Despite the desire to achieve, you need to listen more and seek to understand before ensuring you are understood.

Listen first and ensure others have their say as it creates better teamwork. Leading and achieving can quickly follow effective listening.

Lesson 3: Relationships are just as important as the PM mechanics.

Project managers need to focus on relationships, stakeholder management, and effective communication as well as the usual project mechanics, templates, and processes. I’ve worked with talented project manager mechanics who can do amazing things with scheduling tools and can quote the PMBOK, but they can’t build effective relationships with their business partners.

I’ve made the mistake thinking I’m communicating in project management metrics only to realize the stakeholder had no clue what I was talking about and provided feedback to my managers. I’ve also had stakeholders support my position because I had great relationships despite a challenged project.

I’d tell the young me to be aware of the relationships you have with your stakeholders and the relationships they have with your management. These relationships can affect your career more than properly quoting schedule variance.

Lesson 4: Make your vendor successful.

When managing an outsourced project to an onshore or offshore vendor, recognize it is your job to make the vendor and the project successful. Ignore the high bill rates and avoid blaming the vendor entirely for project challenges. Your company selected the vendor to help the organization. You may not be directing the work, but it is still your job to help them be successful. In return, you will be successful

Lesson 5: Build a foundational understanding of the technology.

If your team is implementing new technology, invest in an online training course to get a foundational overview. Pluralsight, Udemy, SkillShare, and Lynda.com all offer short technical courses that will help PMs understand the technology they are managing.

With a foundational understanding, you can participate in the higher-level technology discussions and ask better questions. I’ve been in meetings where I was told the requirement was technically impossible, but after asking a few questions based on the technology, we were able to find a solution. If you have a strong foundation, you’ll be unshakeable.

Lesson 6: Your career will be a sine wave instead of a positive slope.

Fresh out of college, I had a career plan and knew exactly where I would be at five-year intervals with an ever-increasing salary and regular promotions. That plan (luckily) worked for the first 5 to 10 years but was later affected by economic downturns, corporate restructuring, corporate politics, and job changes.

Your career will have ups and downs like a sine wave instead of a guaranteed positive slope. Sometimes you make more money, and sometimes you will make less money. Yet you will always have a skill set that will provide an income and hopefully longer positive runs than negative downturns.

Lesson 7: Enjoy the ride.

You’re going to spend the next 30 to 40 years working for someone or working for yourself. Retirement, a healthy 401(k), and financial independence are a long way away. Enjoy the work, and don’t be afraid to leave for better experiences. You’ve got years to work, so you might as well as enjoy the journey.

We Don’t Have a Time Machine

Unless Marty McFly shows up in your driveway, you won’t have a time machine to go back and mentor yourself. That’s OK!

You can still reflect on what you can do differently in the future and change. All the positive and negative experiences contribute stories, memories, and learnings to your professional history and career!


Stop Setting New Year’s Resolutions—Set Sprints Instead!

| Comment
Advice Featured LiquidPlanner Project Management

Does anyone else struggle with setting and achieving New Year’s resolutions?

I’m sure you’ve experienced the futility of setting New Year’s resolutions only to continue the same pattern of human behavior from the previous year. Another year goes by and you wonder why you haven’t accomplished the goal you set the last time the ball dropped in Times Square.

New Year’s resolutions are useless without a plan. Even when I build a plan, it is too lofty to follow as work and life provide a stream of interruptions. This year instead of setting New Year’s resolutions and long-range goals, I’m establishing short-term goals with personal sprints!

Sprint Your Way to a Healthier You

Weight loss is a common goal for many people after gorging themselves on dinner with second helpings and holiday celebrations. The food fest starts with the Halloween candy injection and Thanksgiving turkey overload and then continues through the corporate holiday parties and New Year’s overindulgence. The birth of a New Year suddenly motivates all of us to get a little healthier, but without a plan, weight loss becomes a running joke with an unused gym membership.

Building and tracking a weight loss plan is a pain as it requires work and is daunting even when simple tasks are defined.

I used LiquidPlanner to model a simple 20-pound weight loss goal by setting up daily tasks over the course of 10 weeks.

Building a daily task list for 10 weeks creates a long list of activities. The plan includes all the reminders to shop for healthy groceries for the upcoming week, making a smoothie for breakfast, logging calories in a fitness app, and ensuring lunch and dinner have my caloric intake in mind.

Of course, the plan also includes a few days of exercise so I can dust off my gym membership card and actually use it. (I’m expecting Planet Fitness to throw a welcome celebration!)

The downside of this plan is it still looks overwhelming. Adopting a sprint model breaks down the overload and makes goal achievement easier.

Instead of focusing on the longer 10-week goal of dropping 20 pounds, I’m resetting the focus for a four-pound weight loss in two weeks. I set up the Card View using the Kanban board for just one week of activities. Each week has a backlog of activities, but I get even more granular by viewing the Card View one day a time.

This view is much easier to manage as the focus is just on the handful of tasks. I track each day’s progress by simply moving a task from To-Do to In-Progress to Done. Each day I have some small satisfaction in accomplishing small tasks that build up to the larger goal. By accomplishing a small set of daily tasks, I’m more motivated to tackle the next day.

This sprint model isn’t only for weight loss; it has a lot of real-world applications!

Writing a Book Is a Marathon of Sprints

If you ever wrote a graduate thesis, doctoral dissertation, or a large term paper, then you know writing isn’t an easy activity. Writing a book is even more difficult as translating the big idea in your brain to paper is a struggle with the big blank page.

Writers use outlines, sticky notes, and even mind maps to brainstorm book content. Delivering a 300-page, 75,000-word-count project by a specific deadline is a daunting challenge from Day 1. Breaking down the marathon writing cycle into smaller chunks and individual sprints will help deliver the writing project. Below, I’ve detailed several chapters of an upcoming book project into the Card view.

It still appears daunting with all the sections that need to be written over the next 5 months, and I only included a few chapters in this plan. Instead of worrying about the deadline months from now, I’m focusing on one-week sprints and setting up smaller accomplishable goals once a week.

Each week, I plan to write 300–500 words a day. By breaking down each chapter into major sections and subsections, I can focus on that specific subtopic. When that topic is completed, I can move it to the Done column.

Accomplishing New Year’s Resolutions Requires Continued Motivation

Accomplishing New Year’s resolutions and long-term goals require continual motivation. If you have a plan with a long timeline, you need to find ways to stay motivated and celebrate the small accomplishments. Setting up sprints to meet your goals is an excellent way to complete small tasks and stay motivated to the longer-term goal. Accomplishing the tasks in your weekly sprint plan will provide small amounts of success, which will further motivate us throughout the year.

Happy Sprinting!


Five Ways to Thank Your Team without Breaking the Bank

| Comment
Featured Teams

With Thanksgiving in a couple of days and the December holidays approaching, I’m reminded of the importance of taking the time to recognize the team. As managers, we should recognize teams frequently, but the end of the year usually provides us with the formal opportunity. Project teams work long hours to deliver seemingly never-ending projects, and it can be exhausting tackling issue after issue. When the project finally ends (and they all do), it is important to recognize the team’s contributions.

Of course, everyone would like more money, but a raise is only a temporary motivator and usually occurs annually. Team celebrations and end-of-year parties always help, but when the budget is tight, managers sometimes need to get creative in finding cost-effective ways to thank their teams for a job well done without having to get CFO approval, even if it means funding them yourself.

Here are five ways to thank your team without breaking the bank or your personal budget.

Team Thank You #1—Grab a Pizza

In Detroit, we’ve got Buddy’s Pizza—a Metro Detroit icon since 1946 with fantastic pizza. I’m sure you have a similar old school pizza establishment in your town. If you’re stuck for a fantastic pizza location, just go to eater.com and search your city for the best pizza. Pizza works great because it appeases the vegetarians and the meat eaters as you can split a couple of pizza pies, salads, and breadsticks. At $20 a pie, the most you’re going to spend on a ten-person team is about $200 for lunch.

In a recent project, our discretionary budget was low, so I split the $200 lunch tab with the other manager. In other projects, I’ve just paid for lunch out of pocket. Spending a Ben Franklin or two and bringing the team together is well worth the team building and relationships forged over a slice.

Team Thank You #2—Buy the First Round of Drinks

It may not be HR approved or politically correct, but team building over a glass of wine or a local craft beer is a good idea! Even if you don’t drink, getting outside the office and socializing with your team members and coworkers helps to improve team relationships.

If you want to reward the team informally, without appearing as “the boss,” simply schedule a happy hour after work and offer to buy the first round of drinks. It is a socially acceptable way to say thanks, let’s relax, and have a beverage.

I recently went to a happy hour with my team and other peers, and we realized that we need to get out more often and simply socialize. We spend so much time in meetings and exchanging emails, texts, and instant messages that we don’t invest time in getting to know one another. Offering to meet up at a local watering hole after work and buying the first round is a nice way to get everyone together.

What if people don’t drink?

I’ll also buy a couple of appetizers, and soft drinks are a low-cost addition to the bar bill.

Team Thank You #3—Get Vendor Swag

If you don’t have the budget to reward your team, chances are your software vendor does! Sales representatives and marketing departments often have discretionary budgets to take team members out to lunch as well as pallets of notebooks, mouse pads, T-shirts, and pens. If your team has accomplished a significant milestone using a vendor’s software solution, simply ask your sales representative if they have any promotional materials.

I’ve done this multiple times and have found vendors are always willing to get their branded material onto people’s desks. That is why they have a marketing budget!

Team Thank You #4—Give a Book

A fun way to reward an individual or a group is with a book! I’m a fan of personal productivity and books that help team members accomplish their goals. Each book is $10–$15 and are excellent ways to thank a team with some knowledge bombs! Below are my top five recommendations.

GRIT: The Power of Passion and Perseverance by Angela Duckworth

GRIT is an inspirational read that cultivates and grows the drive for results and perseverance to deliver despite business challenges.

The Miracle Morning by Hal Elrod

The Miracle Morning provides best practices and sound advice on how to be more productive even though getting up before 5 a.m. can be difficult to do!

The One Thing by Gary Keller

The One Thing help you solve the feeling of being overwhelmed by providing a clear way of prioritizing tasks and to actually make progress towards goals in less time.

Getting to Yes by Fisher and Ury

I read Getting to Yes over 15 years ago, and the importance of a BATNA (best alternative to a negotiated agreement) still stands out and is useful in contract negotiations.

The Adventures of Johnny Bunko: The Last Career Guide You’ll Ever Need by Daniel Pink

The Adventures of Johnny Bunko is an easy and fun career book disguised as a graphic novel.  A perfect gift that reinforces solid career planning principles.

Books make great gifts and last a lot longer than a lunch does.

Team Thank You #5—Pen a Handwritten Note

In the days of Google Docs, Facebook wedding invitations, and pre-preprinted thank you notes, the handwritten note on good ol’ stationary is still a welcome and thoughtful thank you. One year I received a personal thank you note from our IT director written on her own personal stationery. I was impressed she had her own monogrammed stationery but was even more impressed she had taken the time to write a few thoughtful words recognizing the accomplishments.

It only took her a few minutes to put meaningful words to paper, yet it is a thank you I still remember!

Thanking your team doesn’t have to break the bank. It always helps when the company can fund a nice evening out for the team or a lunch that goes beyond $8 per person. However, budgets are tight, and if you can’t get your company to fund team recognition, hopefully, these ideas will help!

How do you thank your team? Let us know in the comments below.

 


Michael Myers—Performance Review

| Comment
Featured

In the workforce, everyone receives an annual performance review—even horror icons like Michael Myers. Since 1978, Michael Myers has demonstrated his perseverance in pursuing his sister, Laurie Strode, nearly a dozen times!

The Horror Icons of America Guild (HIAG) recently completed Michael’s latest performance review, and this lucky reporter was able to secure a copy to share with you!

Horror Icons of America
Performance Review
Employee Info
Employee Name Michael Myers Department Horror
Employee ID 10312018 Reviewer Name Jason Voorhees
Position Held Horror Legend Reviewer Title Supervisor
Last Review Date August 28, 2009 Today’s Date October 19, 2018
Current Responsibilities
●     Eliminate the family tree including Laurie Strode and any other siblings or relatives.
●     Avoid capture by Dr. Loomis and any related psychology and law enforcement staff.
●     Successfully escape from mental hospitals or secure police transportation.
Performance Assessment
Evaluate performance and achieved goals.
Mr. Myers displays a tremendous drive for results as observed in 10 different attempts to eliminate his family bloodline.
He has consistently displayed perseverance and dedication to his work by working extremely late hours and overcoming obstacles (usually in the form of teenage miscreants).
He demonstrates a commitment to the work by overcoming gunshots, fiery explosions, and multiple stab wounds in his efforts to remain alive. This commitment goes above and beyond the expectation for our employees.
Despite these strong leadership behaviors, Mr. Myers has failed to successfully capture and eliminate Laurie Strode numerous times, despite the opportunity being presented to him every few years.
Discuss areas of improvement.
Improve communication. Though he is fully capable of speech, Mr. Myers rarely communicates verbally. Establishing better communication as he interacts with others will help him achieve his goals. Pursuing a local Toastmasters International club is encouraged.
Avoid distractions. Mr. Myers should avoid distractions, such as approaching college students in compromising situations. Doctors, nurses, police officers, security guards, and any other people should be avoided. This will enable Mr. Myers to focus clearly on his main goals.
Apply critical thinking. At nearly 62 years of age, Mr. Myers should have a lifetime of experience to learn from and apply to problems and challenges. He would benefit from better decision making and learn to avoid gunshots or taking on knife attacks head on. Although he pursues work at his own pace, he could achieve his goals faster by running versus his slow mechanical walk.
Improve teamwork. Given Mr. Myers has failed to achieve his goals multiple times over the past four decades, he should look to leverage a team of movie monsters rather than pursue his target alone. He is encouraged to speak with Vlad the Impaler, the entire Aliens department, and the cast of the Wrong Turn franchise on how to build a team for effective execution. He should also note the failures from Frederick Krueger, Charles Lee Ray, and Norman Bates for future lessons learned.
Develop future goals with set expectations.
For 40 years, Mr. Myers has been trying to eliminate his sister, Laurie Strode. Through his previous 10 attempts, Mr. Myers has only been successful once in attaining his goal; however, multiple reboots have resulted in him having to start from scratch. Our hope is that, with the next installment of the Halloween series, Mr. Myers will exceed expectations.
Comments and Approval
Provide any additional feedback.
●     Employee declined to provide feedback or acknowledge the review.
Employee Signature Reviewer Signature

Happy Halloween!


Three Real Agile Team Challenges and How to Solve Them

| Comment
Advice Collaboration Featured LiquidPlanner Tips

Agile means a lot of different things to different project teams.  Many teams I meet describe themselves as “Agilish” or use “Scrumerfall”.  These teams struggle with Agile practices as business analysts author reams of business requirements only to have a development team write the user stories.  Business representatives assume the product owner role but only check in with their team at the sprint review.  My personal favorite is adding more scope to an active sprint and the team wonders why they can’t meet their velocity goal.

Many of these issues stem from getting the Agile roles and processes right at the start of the project.  According to the Scrum Guide, a scrum team has only a few roles by design – Scrum Master, Product Owner, and the Team.  In Dean Leffingwell’s book, Scaling Software Agility, he favors eight or fewer team members including product owner, developers and testers.   If you have recently obtained your 2 day Certified Scrum Master (CSM) certification, you are likely excited to transform you team with renewed enthusiasm.

Then you take this newly acquired knowledge and real life hits.

Real World Agile Challenges

How many of you have experienced these real-life scenarios?

  1. The development team is distributed
  2. The development team is a 3rd party vendor contracted for a fixed scope with their own software practices optimized for their organization
  3. The product owner has the title but doesn’t perform the product owner role.  The team then typically struggles with identifying and prioritizing business needs, receiving timely feedback and managing change.

Even though the Agile ceremonies aren’t hard to understand or follow, Agile implementations still struggle if the roles are not correctly understood.  Fortunately, there are some Agile approaches to overcome these real-world challenges.

#1 Agile with distributed teams

Co-location is helpful but it isn’t always realistic as organizations scale their Agile implementations.  Finding competent local talent isn’t always possible and organizations often select firms located across the country.  If the development team is located in different regions, the Agile practices can still be delivered using Skype, WebEx, GoToMeeting or your favorite video conferencing tool.  The key is ensuring there is enough communication between the team members including the product owner.

In one of my global programs, we ran two Agile teams distributed in the United States and Europe.  The team conducted the Agile ceremonies supported by WebEx and also traveled quarterly to the global headquarters.  The team was effective at delivering the backlog but also recognized the value in co-locating for important periods of time.

The key takeaway is to co-locate for a short period of time and communicate daily across multiple channels.

#2 Managing the outsourced vendor with their own software methodology

In an outsourced relationship, the company is entirely dependent upon the vendor’s ability to deliver according to the vendor’s methodology.  I’ve seen wonderful Agile presentations from vendors claiming Agile expertise only to see it fall down due to their own internal development process.  If you can’t influence or control the vendor’s software delivery process, Agile techniques can still be applied to define user stories and prioritize the most important features.

In a mobile software development project, the vendor claimed to be Agile but delivered in a Scrummerfall manner with two weeks of development followed by a week of testing.  The team struggled with changes as requirements were elaborated.  The business viewed changes to requirements as defects in the software and the vendor insisted the requirements were not provided accurately nor part of the original contract.  Meanwhile, the timeline kept ticking by with a launch date approaching.

The best the team could do was to ensure bi-weekly feedback while they spent an enormous amount of time defining the product backlog.   It wasn’t an ideal Agile approach but the team delivered after 6 weeks of system and user acceptance testing.

In hindsight, it would have been better to contract with the vendor on a resource based model allowing the project team to drive scope and determine how the project would be implemented.  The scope would be jointly managed rather than contractually managed.  This approach puts more risk on the project team but also ensures both the vendor and the project team can function as one team.

#3 Product owner by name only

In traditional IT, the business customer provides high-level requirements to an IT team and accepts or rejects the solution after reams of process flows and requirement documentation.  With Agile, the business customer has a new title – product owner – and is expected to collaborate with the team to define needs, refine the product backlog and prioritize features for each sprint.

This doesn’t happen as easily as anointing a business customer with a new title.  The reality is the business customer already has a job running the business.  It becomes difficult for a business customer to run the business and engage in all the Agile processes.  I’ve seen product owners disappear for a week because they were pulled into a crisis or had to resolve a business problem.  Consequently, the team struggled with prioritization and feedback.

One approach is to allocate a “product owner by proxy”—an empowered business analyst or additional resource who is not running the day to day business but can help define the product needs while getting appropriate feedback between the product owner and the team.  The product owner still needs to engage the team by attending sprint reviews, however, the proxy product owner engages in the day to day sprint execution.  This model, although not ideal, still provided enough feedback to the team to develop the right product.

 

Agile isn’t as easy as it seems

Agile in a textbook and in implementation are two different stories.  Teams just don’t become Agile by reading a book or taking a certification course.  It takes time putting the Agile theory into practice and optimizing the Agile processes within the team.  Executing the Agile ceremonies help identify pain points within the team and the retrospective helps to make improvements frequently.

Adopting agile techniques appears easy but challenges quickly appear if the organization doesn’t solve for solutions to distributed teams, fixed-price contracts or insufficient resources and roles.  The challenges previously mentioned are just a few of the roadblocks teams will encounter as they adopt Agile practices.  If the team focuses on developing software incrementally with quick feedback loops that enable teams to embrace change, then challenges can be addressed head-on.


Top-Down vs. Bottom-Up Project Management Strategies

| Comment
Featured Project Management Teams Tips

“How long is that going to take?”

As project managers, we’re driven by dates. Customers, senior managers and stakeholders all want to know how long it will take to complete a project. And as project management professionals, we’re also measured by our ability to predict the future and be right about our predictions—despite the many unknowns. To answer the “how long” question, we have to plan the project, define tasks and gather estimates from the team.

When planning a project, the two most common questions, I ask up front are:
  1. What are the tasks?
  2. How long will the tasks take?

These are relatively simple questions, yet the project management field has developed many different techniques to answering these questions. For example:

When you define the tasks, do you:
  • Follow a prescribed template or formal “standard” to plan the project?
  • Do you look at past projects for similarities and reuse their project schedules as a starting point for project planning?
  • How do you use top-down or bottom-up approaches to plan your project?
When you estimate each task’s duration and cost, do you:
  • Ask a bunch of experts
  • Use a similar project’s estimates
  • Apply top-down planning
  • Spend more time building a bottom-up estimate?

When you look at the various techniques, there are a lot ways to answer those original two simple questions I pose at the top of this article.

Here’s a look at how to use top-down and bottom-up planning to identify and estimate your project tasks.

Question #1: What are the tasks?

Using the top-down approach

The top-down approach to defining project tasks involves starting with the project goal or final deliverable, and breaking it down into smaller planning chunks. We call them work packages. Each of these work packages or “chunks” is further refined into greater detail, and then work items are assigned to team members.

The top-down approach works well when there’s clear insight into the details of a project, and the leading project manager has a big-picture of how the project contributes to the organization.

The benefit of top-down is that the major tasks are quickly identified, and the details are later refined by the project team. However, the downside is that details might be missed without a detailed review by the project team.

A top-down example

Let’s say you’re responsible for upgrading your application’s hardware and software layers. Based on past experience, you know you’ll need to install a new server, install the upgraded operating system, and then install the latest version of the application software. These are all top-down tasks that can be assigned to a project team to implement. The risk is that the application software doesn’t work on an upgraded software layer due to a conflicting API or compiled library. The challenge is in all those pesky details that impact your project.

Using the bottom-up approach

The bottom-up approach to answering “what are the tasks” relies on project team members identifying the tasks and then organizing them into specific groups or work packages. If you applied a bottom-up approach to identify tasks for the software upgrade mentioned above, the entire project team would brainstorm all the tasks required to correctly upgrade the system. There’s also a greater chance that a team member will identify an operating system conflict or at least include a step to test that feature than in top-down planning. Ideas get flowing and tasks can be written down on sticky note pads or index cards. All these tasks can then be logically grouped into categories that make up each work package.

The bottom-up approach results in a more detailed schedule, but it’s also a time-consuming approach compared with the top-down task planning approach. The schedule you create is based on direct input from experts who will be implementing the project; it’s also a useful technique to build teamwork.

If your organization doesn’t have previous experience with the type of project you’re trying to plan, this approach helps identify unknown tasks.

Question #2: How long will the tasks take?

Once you have the tasks, the top-down or bottom-up estimation approach can be applied.

Using the top-down approach

The top-down approach to “how long” is usually done by managers for budget planning, portfolio planning or for conducting feasibility studies. In these cases, a great level of detail isn’t known and there are many assumptions made with potential inaccuracies.

I’ve used this approach when planning the next year’s project portfolio, and estimating the number of resources required while developing a rough project timeline and cost estimate. At this stage, I don’t know the full detailed scope, but I know I need people and a budget to complete the project. During the project planning phase, I’ll detail the specifics and refine the actual costs.

Using the top-down approach, the project timeline and cost accuracy isn’t very precise, as detailed planning hasn’t begun. The cost and timeline can be used as a range or a guideline, but formal budget and date commitments should wait until detailed planning has completed. The benefit of using the top-down approach here is that funding and resource planning can be done quickly through consensus. The trade-off is that project cost and schedule dates aren’t as accurate.

Using the bottom-up approach

The bottom-up approach to “how long” is my preferred project estimation method—but it takes a lot more time than top-down planning. In the bottom-up approach, the project team has defined the tasks and can make accurate estimates at a detailed level. Then, the sum of these estimates and task dependencies within each work package determine the total cost and timeline for the project schedule.

This technique is useful for developing detailed project budgets, schedules and monthly forecasts. And, it helps define the specific resource skills needed during key phases of the project in order to get a more accurate schedule. The tradeoff of using a bottom-up approach is that it requires more time.

Investing in the right approach

Project managers and stakeholders all want an accurate accounting of time and project costs. However, this level of accuracy costs money and time to produce—which means project managers and stakeholders need to balance project accuracy with project delivery.

I’ve been on some projects where the team had the luxury of spending several months to plan a project. More often than not, I’ve found that the project team is asked to meet a committed date in the future based on a top-down planning exercise. In these situations, I’ve conducted the bottom-up planning, identified the potential unknowns, and use time to further detail those unknowns and mitigate potential risks.

A bit of both

Project planning can rely on both top-down and bottom-up planning techniques. The technique you choose depends on your specific planning goal. If you’re pursuing a portfolio planning goal, you’ll likely do a lot of top-down planning and let the project team work out the details.

If you’re the project manager implementing the current year’s plan, you’ll apply a bottom-up approach to validate the timeline and your initial budget assumptions. You can apply both of these techniques to answer “How long is that going to take?” The real project challenge is in predicting the future and being right!

Being able to accurately estimate project work is one of the best tools you can have to answer the”how long” question. To master your project estimation skills–and learn about some methods–download our eBook, “6 Best Practices for Accurate Project Estimates.”


Import Your Work Breakdown Structure Into LP with Zapier

| Comment
Featured LiquidPlanner Productivity Tips

In my previous article, I demonstrated how to take project requirements and integrate them with LiquidPlanner using Zapier, a web-based application integration tool. Leveraging technology to automate administrative tasks is an excellent way to reduce a project manager’s administrative burden. Zapier makes this even easier with LiquidPlanner.

In this article, I demonstrate how project managers can import work breakdown structures into LiquidPlanner using Zapier.

Work Breakdown Structure Tools

There are a lot of different ways to develop a work breakdown structure including sticky notes, outlines, Visio, and scheduling tools. One of my favorite methods for brainstorming scope and developing a work breakdown structure is with mind mapping software. For this exercise, I am using Mindjet MindManager to develop the work breakdown structure. The latest MindManager release has built-in support for Zapier integration!

In this work breakdown structure, I’m developing the scope and task list to develop Grandpa’s Cabinets, a custom display case business. Grandpa’s Cabinets is a small business that develops acrylic display cases for model ship, airplane, and other scale modelers who want to protect their models and display their artwork attractively.

Using MindManager, I created the following work breakdown structure.

For each major section of the website, I defined several key tasks. For the Request a Quote page, I’ll need to do the following:

  1. Develop the Request Form
  2. Email Submission Results
  3. Store the data in the database

Instead of copying all these tasks from MindManager into LiquidPlanner, I will use the Zapier integration feature to send them to LiquidPlanner. Before I can send the zap, I need to configure the integration using the following steps.

Step 1: Login to Zapier and Make a Zap

Login to your Zapier account (http://www.zapier) and click the Make A Zap button. The Choose A Trigger App screen appears and you will need to search for the MindManager application.

Since I’ve configured zaps with MindManager and other applications before, the selection appears in the dashboard automatically.

Step 2: Select MindManager Trigger

With this Zap, there is only one option for the MindManager Trigger. A MindManager topic will be sent to Zapier when it is zapped within the mind map.

Step 3: Connect MindManager to Zapier

Sign in to your MindManager account within the Zapier environment to make the connection. You’ll only need to do this once as each connection is reusable when you create different zaps.

Step 4: Test the MindManager Connection

Clicking Continue will connect your MindManager account with Zapier and pull in a sample topic. The sample topic is used to configure the Zapier to LiquidPlanner integration in further steps.

Step 5: Select the LiquidPlanner App for the Action

The next step is to specify the LiquidPlanner application for the Zapier action. Multiple applications can be triggered from one Zap. If you wanted to integrate with LiquidPlanner and send the same work breakdown topic to a Slack channel, you can add additional actions. For now, just select the LiquidPlanner app to configure the first zap.

Step 6: Specify the Action

Similar to the previous tutorial, you will create a new task in LiquidPlanner with each Zap. You can also create a separate Zap to update existing tasks in LiquidPlanner. I’ve found once the WBS is in LiquidPlanner, you’ll want to manage the work in LiquidPlanner because the scheduling engine provides a useful forecast.

As in the screen shot below, just select Create a Task.

Step 7: Connect Zapier to the LiquidPlanner Account

If you followed my previous tutorial, your LiquidPlanner account will already be connected to Zapier. If you need to connect to a new account or modify the LiquidPlanner account, connect and test the access to the LiquidPlanner in this step.

Step 8: Setup the LiquidPlanner Task

In this step, you will configure the integration between MindManager and LiquidPlanner. For this integration, I keep it simple and map the task name to the node in the mind mapping file. By clicking on the Insert a Field icon on the right, you can select from a variety of mind mapping file attributes.

Step 9: Send a Test Task to LiquidPlanner

The Test this Step process will send a test transaction to LiquidPlanner. Ensure the integration works correctly and check your LiquidPlanner account to see if the sample task was successfully sent.

Step 10: Turn on the Zap

Enable the Zap by clicking on the toggle icon.

Step 11: Zap Your Mind Map

In Mindjet MindManager, select Advanced – Zapier and confirm the account is connected to Zapier. Then select multiple nodes in the map, right click and select Send Topics To, and select the Zapier option.

With a couple of clicks, you’ve sent the WBS package to LiquidPlanner for further schedule development.

Step 12: Build the Schedule in LiquidPlanner

Go into LiquidPlanner and check the Inbox. You will see all the nodes that were sent from the mind map in your LiquidPlanner account.

MindManager + LiquidPlanner + Zapier = Easy Scheduling

Combining a mind mapping tool like Mindjet MindManager with LiquidPlanner makes it easier to schedule tasks and build an overall project schedule. Defining work often results from a brainstorming session as teams figure out their project scope and assign action items.

A mind map is an excellent tool to gather requirements, organize scope, and communicate with visual thinking.

By integrating the tasks with LiquidPlanner, the project manager saves time and the team can start collaborating on tasks easier. Compared to traditional single person desktop tools, this solution enables team to work faster without a ton of administrative overhead.

As web-based management tools continue to grow, project managers can leverage Zapier and LiquidPlanner for more project management automation.

New to LiquidPlanner? Start your free 14-day trial today!


Zapier Integration: How to Go from Requirements to Project Schedule in a Zap

| Comment
Featured LiquidPlanner Tips

As a project manager, how often have you experienced these scenarios:

  1. You just walked out of a requirement gathering session and have an Excel list of new project requirements that need to be organized into a schedule
  2. Your team has developed a user story backlog in JIRA but you need to represent the sprints and key dependencies in a project timeline
  3. You realize several key meeting minutes are actually project tasks that need to be incorporated into the project schedule

All of these scenarios happen daily to project managers. Project managers also use a variety of tools to develop scope, gather requirements, track action items, and organize for delivery. When these individual items need to be organized into a project schedule, the project manager has to synthesize the requirements, organize the actions and to-do list, and reformat them into a project schedule.

All of this increases the project manager’s administrative burden which is counter-productive to leading the team and driving for delivery.

Fortunately, LiquidPlanner can help reduce this burden with its nifty Zapier integration.

What is Zapier?

Zapier is web-based application integration and automation solution that allows online applications to interact with each other. There are hundreds of automations and integrations available on the Zapier.com platform. A quick review of the prebuilt connections (also called Zaps) are available for LiquidPlanner, JIRA, Trello, Salesforce, Google Docs, and Gmail.

What is a Zap?

A Zap is an integration between two applications. A zap is configured within a few minutes by configuring a trigger and an action between two applications. Creating a Zap uses a simple process where you define a trigger in one application and then an action in the receiving application.

In the scenarios above, I configured Google Sheets to send a new task to LiquidPlanner for new requirements and user stories. It is very easy to configure the Zap integration as the Zap editor walks you through triggers and actions across both applications. Zaps can be customized to work on specific data filters and default specific values in the Zap action. Below are a few Zaps I created to address the aforementioned project management scenarios.

In the tutorial below, I’ll show you how to send requirements in Google Sheets to LiquidPlanner. By following the simple configuration process, you’ll be building integration between your favorite web-based applications quickly.

Google Sheets to LiquidPlanner Zapier Integration

Step 1. Choose a Trigger App

The first step is to choose the source or “trigger” application. Zapier has hundreds of applications to choose from and the platform continues to grow. Because we’re integrating Google Sheets, search for Google Sheets in the Choose a Trigger App search box.

Once you configure an application, it is always available to you in the dashboard.

Step 2. Specify the Trigger

The next step is to select the specific trigger within Google Sheets that initiates the event. In this example, I want to send any new rows or updated rows in Google Sheets to LiquidPlanner.

Step 3. Connect Google Sheets to Zapier

You will need to sign into your Google account within the Zapier environment to make the connection. Once you sign in, the account will be reuses for any new Zap you create.

Step 4. Setup Google Sheets Options

Once the account is connected, you need to specify the Google Sheets options. In this Zap, I include the Google spreadsheet name, the specific sheet, and any column options. In this Zap, the Google spreadsheet only has one sheet called “Scope”.

Step 5. Test Google Sheets Connection

Zapier will test the Google Sheets connection as it attempts to retrieve a row based on the criteria specified in Step 4.

Step 6. Select an application for the Action

The next step is to specify the target application for the Zapier action. Now that Google Sheets is configured as the source, the next step is to select LiquidPlanner as the target application for the action.

Step 7. Specify the Action

With each target applications, there are many different actions that can be taken within the selected application. LiquidPlanner provides many different actions including creating tasks, updating tasks or adding comments. Zapier maintains a list of common target actions and less common actions depending on your integration needs.

Step 8. Connect Zapier to the LiquidPlanner Account

Once the target application is defined, you need to connect the application to your LiquidPlanner account similar to Step 3 when you connected Google Sheets.

Step 9. Setup the LiquidPlanner Task

Once the account is authenticated, LiquidPlanner needs to be mapped to the data coming from Google Sheets. If Task A was the sample task in Google Sheets, it will appear in the LiquidPlanner mapping. In this example, I sent Task A with an low estimate of 4 hours and a high estimate of 8 hours. These are just a few of the basic fields that can be configured. Depending on the business needs, different mappings can be created based on the trigger.

Step 10. Send a Test Task to LiquidPlanner

Once the integration is configured, send a test task to LiquidPlanner. Once the integration is a success, you’re just a few clicks away from enabling the Zap.

Step 11. Turn on the Zap

Once the Zap is confirmed to work, enable the Zap and it will run every 15 minutes integrating Google Sheets with LiquidPlanner.

Step 12. Add tasks to Google Sheets

Go ahead and open the connected spreadsheet in Google Sheets and add some tasks.

In this example, I documented several user stories and tasks needed to launch a small website.

Step 13. Wait 15 minutes or run the Zap from the dashboard

If you want immediate gratification, go ahead and run the Zap from your Zapier dashboard.

Otherwise, you can continue to update the sheet and go to lunch. When you get back, the tasks will be submitted to LiquidPlanner.

Step 14. Continue Planning in LiquidPlanner

Once the tasks are in LiquidPlanner, you can plan the tasks as you normally would in LiquidPlanner. The tasks show up in the Inbox much like the tasks you email into LiquidPlanner.

Go ahead and re-assign the appropriate resources, make any estimation tweaks and recalculate the Gantt chart.

It may seem like 14 steps is a lot to configure the integration but it is very quick and easy to setup the two applications.

Benefits

As more companies adopt web-enabled project management tools, the role of “middleware” connecting robust applications will only continue to grow. The Zapier integration helps the project manager save time, reduce the administrative burden, and share project data across project management and collaboration tools. It’s actually “fun” to use. Well, as much “fun” as a project manager can have on a project.

More LiquidPlanner Zaps

There are many different Zap configuration available for LiquidPlanner. If your team is using JIRA to build a product backlog but needs a meaningful Gantt Chart, the LiquidPlanner Zapier integration will build a useful project timeline.

If you are managing operations using the Kanban board in Trello, a Zapier integration will update the task status within LiquidPlanner. Agile and Kanban approaches are excellent ways to build software yet stakeholders still want to know when their specific feature will be delivered. Integrating with LiquidPlanner will help answer the timeline question as well as enable to team to remain Agile.

For a complete list of ways to automate LiquidPlanner in Zapier, check out https://zapier.com/apps/liquid-planner/integrations. In a future tutorial, I’ll show you how to convert a work breakdown structure into LiquidPlanner with an on-demand Zap.


Using Agile Practices to Improve Business Customer Relationships

| Comment
Featured Methodology Project Management Teams

The relationship between IT and Business teams has rarely been heralded as a model for organizations to follow. The relationship is typically strained with IT being too slow to respond, expecting business teams to “define ALL of their requirements upfront” and long lead times before a product can even launch.

Business teams struggled with understanding their role in a software project while trying to sort through all the technical jargon used to build a website. Add external consultants promising to do the job faster in an environment they don’t control and internal security and PMOs adding their processes, it isn’t a wonder the Business-IT relationship is challenged.

Related: Adopting Agile is an Exercise in Change Management

Given these challenges, how does applying Agile practices improve the relationship? IT and business teams speak entirely different languages and the recommendation is to introduce terms like scrum, product owner, sprints, backlog, user stories and story points?

Yep.

Adopting Agile practices introduces new terms and new ways to work as a team. As a result, the relationship is improved and trust is developed through frequent and demonstrable results. Below are two examples from past projects.

Example #1 : Failing to Deliver

The global marketing team had spent the past 18 months working with product, engineering and supply chain teams to develop a “best in class” website for online ordering, integration with ERP systems and marketing and sales functions. The project followed a waterfall methodology with 25-page documents describing each major feature and required scope.

The project scope continued to grow and the 18-month project became a 24-month project riddled with software defects. In order to make the mandated launch date, the team cut scope and launched a solution that only met the online ordering need.

Related: Agile Team Transitions are Not Always Textbook

Even though the project was outsourced to a 3rd party vendor, the business teams blamed IT for failing to deliver. Marketing was frustrated that none of the customer relationship management or marketing features were included in the launch. IT leadership changed and the software vendor ramped down their outsourced army of developers. The business was left with half developed features that no one really wanted.

Second Chance

With the following year’s budget cycle, additional funding was provided and a new business and IT team applied an Agile approach to add new features to meet marketing’s needs. The team included the business acting as a product owner, internal IT managing the project and a 3rd party development team who had expertise in Agile delivery. It took several sprints to establish a rhythm but the Agile process provided the transparency, demonstrated working software and provided flexibility for the business to change requirements.

Previously, the business team defended their position that they “provided all the requirements 9 months ago” and were quick to criticize. Using the Agile processes with a 2-week sprint, the business shifted to being more collaborative as their requirements evolved and changes were implemented. The key differentiators that improved the relationship included:

  1. Transparency – All team members understood the work in progress and each product’s status
  2. Metrics – Adopting user stories allowed the team to track individual features across sprints and software releases
  3. Demonstrate working software – The team saw working software every two weeks instead of 25-page documents promising features in the future
  4. Embracing change – The team had the flexibility to re-prioritize the work and the product owner knew they could get what they want in 2-week chunks

The end result was a successful project delivering features the business wanted while improving the trust and collaboration between the two teams.

Example #2: Struggling Software Project

This example occurred in a different company, yet shared the familiar story of a complex struggling software project. Project teams attempted rolling planning every quarter only to have the launch date continue to move with each quarter.

Teams tried the Big Design Up Front approach with management expecting the teams should know all the requirements after spending the past 12 months in analysis.

The core application team struggled with delivery as half the team worked off-shore and only had six overlapping hours of collaboration. The application team had a project schedule yet the project manager and the development team were not aligned on task status. The business was also frustrated and doubted the team’s competency and ability to deliver.   

Adding Agile

 A new project consultant joined the team and reintroduced the good Agile practices with a daily standup, prioritizing the product backlog and implementing in 2-week sprints. The project team collaboration with developers and the business improved due to: 

  1. Reviewing the sprint board in the daily stand up
  2. Holding team members accountable to their user stories in the sprint and in the daily stand up
  3. Providing transparency, accountability and communication to the team
  4. Confidence in the team increased by sharing burn down charts and demonstrating working software at the end of each sprint.

The end result was the project improved through the daily and bi-weekly feedback loops. Working with an offshore team presents time and communication challenges, but the Agile process improved the way the team worked to deliver the release.

The project manager still tracked the major features, sprints and releases in a project schedule, but the Agile process helped improve the team communication. Previously, the business had no visibility into the team’s progress and with Agile, the business had more transparency into the day to day activities.

Remember Agile Isn’t a Cure-All

Keep in mind incorporating Agile practices with your business partner and a delivery organization isn’t a magic cure-all or a silver bullet for project challenges. In the example above, the marketing customer was pleased with the result.

However, the executive marketing stakeholder was frustrated the team didn’t deliver everything. I was on a phone call when the leadership team expected a large feature to be delivered and it was the first time I had heard about it.

Related: 7 Ways to Sell Agile Project Management

Agile won’t fix stakeholder management and properly managing expectations. You still need to ensure stakeholders at the project, management and executive level are all aligned on the product direction. If you start adopting more frequent feedback and demonstrating frequent delivery, the business relationships will improve!


A Cheat Sheet for Project Manager Knowledge Transfers

| Comment
Advice Featured Project Management Tips

Project methodologies often have a template to initiate a project or checklists to ensure a project is ready to pass a tollgate or a formal project milestone. If you look at your company’s own methodology, you will likely find a lot of templates for your project.

Despite all these templates, few methodologies have a checklist for project turnover. Project turnover should be minimized, but project manager changes are a reality.

I’ve seen project managers get promoted, moved to different projects, quit or simply be replaced. When I was a business analyst working on a strategic HR systems project, the director replaced the project manager three times! If you find yourself having to transition a project or inheriting a new project, I found it helpful to have a PM Knowledge Transfer cheat sheet.

The cheat sheet is grouped into several areas:

1. Project Overview 7. Project Financials
2. Project Stakeholders 8. Project Quality
3. Project Scope 9. Project Log
4. Project Team 10. Project Document Management
5. Project Governance 11. Vendor Management
6. Project Schedule 12. Advice

1. Project Overview

This section speaks for itself, however, if you have a project charter, be sure to review it. Many organizations lack a quality charter but the key is to review the purpose of the project, high level goals and expected benefits. By providing the “big picture” view, it helps to provide context. Without this context, the incoming project manager will have to stumble through the same points you did when you started the project. Why not make it easy on the new guy?

Get a PDF version of this cheat sheet here.

2. Project Stakeholders

Every project has stakeholders ranging from the Big Boss (i.e. sponsor) to the Little Guy (individual team members). Identify any key stakeholders, their influence and expectations on the project. Who are the stakeholders who will help remove roadblocks? Who has influence over the project outcome? Who is just a pain in the @#$?

Related: How to Build Strong Relationships with Stakeholders

3. Project Scope

What is the project actually delivering? What deliverables have been explicitly called out of scope? What deliverables might be creeping back into the project? What are the project constraints (budget, time, mandatory deliverables)? Are there any assumptions or dependencies to be aware of?

If the project is in execution, scope has likely changed from the original scope statement or original agreement. I’ve inherited plenty of projects where I reviewed the original scope and the team explained how scope changed. I’ve always found a context diagram to be a useful tool to convey all the people, vendors, and organizations involved with the project.

4. Project Team

Every project has its own unique cast of characters, politics and social dynamics. Understanding the personalities, strengths, challenges and idiosyncrasies with each team member will help the new project manager significantly. Be sure to identify the key team members that the project manager can count on as well as any team members who need that extra helping hand.

5. Project Governance

How is the project being managed? What is the sequence of meetings throughout the week that collect status, communicate status, track issues and report schedule progress? How often does the project communicate with mid-level management, senior management and / or the executive leadership team? Are there any formal milestones, gate review or PMO expectations for the project? This checklist item includes reviewing the communication plan but it also includes all the governance processes to ensure the project is executing correctly.

Related: Project Governance for Distributed Teams

6. Project Schedule

Hopefully, the project schedule is up to date and it reflects current progress to date and any new forecasted end dates. If you haven’t updated the schedule in a while, remember to update it and walk through the schedule with the incoming project manager. Identify the sections of the schedule that are still developing based on changing scope or priorities.

7. Project Financials

Review all the actuals to date and cost forecasts as well as any outstanding invoices from vendors. Ensure there is a clean financial hand off to the incoming project manager. If the new PM doesn’t have a clean financial view, the person will waste a lot of time chasing down unpaid invoices and working with Finance and Accounting to clarify past costs.

8. Project Quality

In software projects, project quality often refers to software testing and defect management. In manufacturing projects, it is also important to review any outstanding manufacturing defects or unacceptable variances. It is important to understand how quality is being tracked within the project so requirements are implemented and verified throughout the process.

9. Project Log

The project log is another source for current and past challenges within the project. If there are open issues, risks, change requests or outstanding action items, ensure the project log is kept up to date. Project managers can become easily engulfed in project execution that some of these administrative tasks can get lost. If the project manager has the project log review built into the project governance and status reporting processes, the administration is handled weekly.

10. Project Document Management

Where are all the project documents stored? If there are documents on your laptop, ensure they are stored in a central location such as a file server, DropBox, Google Drive or any shared document collaboration repository. Hopefully, the project has good document management otherwise it is another administrative challenge to figure out who has the latest copy of the project schedule, status report or requirements document.

11. Vendor Management

Review the key vendor contacts and any statements of work. If the contract has specific service level agreements, review the steps to ensure the vendor is performing according to the service level agreement. More importantly, discuss the quality of the vendor relationship, personalities and any nuances that influence the vendor relationship.

12. Advice

The previous 11 sections all provide a framework to convey project knowledge, however this section is useful to identify any parting words of advice or any hidden pitfalls the new PM might encounter. If appropriate, provide the current project manager’s forwarding contact information. In the past, I’ve had to reach out to the former project manager to answer new questions about old problems.

If the PM is staying within the organization, this is easy to do. If the PM is leaving the organization, it may be harder to get the contact information. But, I haven’t seen anyone turn down a LinkedIn request if the transition is a positive one.

What if the project manager isn’t there to transition?

Working with a transitioning project manager is actually a luxury versus a guarantee. I’ve inherited several projects where the “project manager” had very little documentation and even fewer project management artifacts.

If you find yourself in this situation, use this cheat sheet as a guide to ask all the probing questions to make you a success on the project.

Even if you’re not transitioning your project, you can use this cheat sheet to confirm you have all the key project management processes up and running within your project. Download a PDF version of cheat sheet here.