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.

Yes, Your Team Needs a Project Manager. Here’s Why

During the annual budget cycle, portfolio planning or even the adhoc “just-go-do-it” project, project management resource planning and funding can be marginalized and even entirely overlooked.

I’ve seen budgets and resource staffing assumptions that state the project only needs 10 percent of a project management effort. Or, even worse, the team doesn’t assign an internal project manager because the vendor is responsible to “deliver the work.”

Executive teams can make the mistake of overlooking project management needs to make the costs fit the budget or poor assumptions about the project’s complexity. Underestimating the amount of project management required to deliver a project is a critical mistake.

Below are five reasons why projects need professional and experienced project managers.

1. Ensure the project is organized to achieve the project goals.

When I’m asked to consult on a project turnaround effort or help get a troubled project back on track, one common finding is the lack of organization.

Teams will indicate they communicate frequently, know the status of milestones and have a good handle of the key project issues. But, I often find these troubled projects lack an integrated project schedule, a published and understood communication plan, as well as simple project artifacts like an issue list, weekly status report, or an updated project schedule.

An experienced project manager will help avoid these problems by ensuring the project is organized for success. A little bit of pre-planning, clarification of roles and expectations, and structure goes a long way to set up a team for success. Without the organization, teams can churn needlessly thinking that they are making progress.

2. Establish a single point of communication and accountability.

Assigning a project manager to a project establishes a single point of communication and overall accountability.

Project management is not a support role. In fact, it is a leadership role that helps deliver the project. In most organizations, a business lead and a project manager lead the communication effort and share accountability in the project delivery.

When stakeholders have questions, the business typically leads the communication. But project-level details are the project manager’s responsibility.

It is also important the business lead and the project manager are aligned on the communication. I’ve worked on several projects where the business lead’s project status viewpoint differed greatly from the project management level detail. Often, it is the small things that matter!

3. Apply experience and lessons learned.

Professional project managers bring a wide variety of experience and knowledge based on thousands of hours of successful and challenged projects. If the team is implementing a project in a new domain or new business process, adding a project manager with past experience will be instrumental to the project’s success. Otherwise, you’ll bear the cost of experiencing those lessons learned the first time around!

4. Project management is your assurance policy.

You’ve just funded a one million dollar project that will take 12 to 14 months to complete. The results will improve sales and overall company growth.

Are you comfortable just letting anyone run the project? Wouldn’t it be better to provide professional, skilled overhead to ensure the project goals are achieved and if problems arise, the resource has the skills and expertise to help?

Adding a professional project manager (usually less than 10 percent of project costs) provides assurance the project will be organized and managed appropriately. I’d like to say it actually provides insurance, but even project management is a sunk cost on successful and troubled projects.

5. Cheaper to invest in the fundamentals now than later.

The reality is projects are hard. Projects introduce new processes, systems, and organizational change that the organization hasn’t experienced. Executives may be hesitant to fund project managers for every project as there is usually a team lead who has demonstrated leadership in the past.

Leadership isn’t reserved for just for project managers, as we expect each team member to apply situational leadership when called upon. However, it is cheaper to invest in the project management function now rather than later in the project.

When executive stakeholders finally recognize the project needs professional help, it is often too late to rescue the project and maintain the original timing. Providing a project manager upfront mitigates the risk of cost and schedule overruns. Assigning a project manager doesn’t mean guaranteed success. However, you will be guaranteed communication of project issues, delays, and solutions based on years of experience.

When projects go off track, the way to fix most projects is to return to the fundamentals of managing scope, time, resources, and quality. It is better to invest in the fundamentals upfront rather than paying expensive consultants to turn around a project and install those fundamentals mid-project.

Agile Team Transitions Are Not Always Textbook

Project teams transitioning to Agile can often struggle with project roles and the overall team structure. Transitioning to an Agile team is a change in mindset, team organization, and the team’s culture.

Common questions include:

  • Where does the project manager fit into the team?
  • Isn’t the Scrum Master the project manager?
  • Who sets the priorities for the software developers?
  • Who gathers the requirements?
  • How does Agile “really work” in an enterprise organization with global teams?

To understand how Agile teams are different, it is helpful to understand how traditional teams are organized.

Traditional Team Organization

The traditional software development team is comprised of the following roles:

Role Responsibility
Business Customer / Client Provide the business process knowledge and requirements subject matter expert
Project manager Manages the project management processes to successfully deliver the project – initiation, planning, execution, monitor, control and close
Technical lead Leads the technical solution delivery and directs software development team
Application architect Designs the application architecture based on the company’s standards, computer infrastructure and network environment
Business analyst Gathers requirements from the business customer
Systems analyst Translates business requirements into specific system requirements for software development
Developers Design, code, and unit test the software solution
Test lead and test analysts Coordinate testing efforts and verify the software solution meets the business requirements
Infrastructure lead Coordinates the infrastructure and server setup
Database Administrator Creates and maintains the database

All of these resources typically come from different resource pools. Delays are introduced as each resource completes their unit of work and submits request to the next team member to complete additional work. If you’ve ever had to introduce new architecture, stand up a server in an enterprise data center, or modify a development, QA or production database, then you’re very familiar with the constraints in this model.

Agile Team Organization

If you pick up a book on Agile or Scrum, you’ll often read about the best teams are self-organizing, cross-functional, and self-directed. The Scrum Guide only defines the three main roles in Scrum: the product owner, the scrum master, and the development team.

Role Responsibility
Product Owner The single person accountable to the product and responsible to ensure the requirements in the product backlog are clearly defined, prioritized, and communicated to the team
Scrum Master Facilitates the Scrum practices, supports the product owner in managing the product backlog activities, coaches the development team,
Development Team The group who does the work to deliver the product

Teams transitioning to an Agile model will wonder what happens to the analysts, the technical lead, the project manager and other traditional roles. Depending on the Agile maturity in the organization, these roles will still exist within the team.

Remember the development team is the group that delivers the product and that can still include a project manager, a test lead or business analysts.

Many organizations talk about being Agile but don’t always have a dedicated product owner who fulfills the role of the product owner. In this case, the team needs to supplement with an empowered business analyst. The project team may not have implemented test automation or test-driven development, so traditional test lead roles will exist.

One of the concepts with mature Agile teams is the team members are cross-functional. This means the skills for business analysis, systems analysis, database development, test automation, and project management exist within the team instead of having separate roles for separate people.

Think about the last high performing team you worked with. The individuals likely shared all these skills instead of relying on separate individuals. My strongest performing team still had a project manager, but that same resource understood business and system analysis as well as testing best practices. The development team also understood the business context and had database development skills.

Conversely, my worst performing team had these skills separated across individual roles. To make a database change in the development environment, a ticket had to be submitted to the DBA team, then escalated because the team wasn’t responding in time. Separate testing resources were allocated for a fixed period of time and often couldn’t test in a timely manner. Consequently, velocity suffered and the team motivation declined.

Not very Agile huh?

Improving with each sprint

Building a team that is cross-functional, self-organizing, and self-directed is an evolution in Agile maturity. The teams I coach today still struggle with reaching this state as many organizations have the silos that prevent teams from working efficiently. Other teams simply struggle with the change from top-down direction to a team centric approach. The good news is adopting Agile practices provides the feedback loops for the team to improve.

During a product backlog grooming session, one of my teams was hesitant to provide individual story point estimates. Team members would look to the team lead for approval because previously the team lead would direct the work. It took a few sprints but eventually the team became comfortable with the new processes. That team is still progressing by adopting different Agile techniques, but they are improving with each sprint.

Transitioning isn’t textbook

If you are implementing Agile practices in your organization, you likely recognize it isn’t a textbook transition. Self-directed, cross-functional, and self-organizing teams don’t appear on Day 1. Until those skills exist within a self-contained team, supplementing with traditional roles is fine. Project teams need to deliver, and adopting an Agile or traditional team formation is still influenced by the leadership team and the existing team skill sets. There are many different approaches to project execution, but I know which team structure I’d prefer!

The Case for Multiple Project Management Methodologies

A multiple-methodology approach to project management may lead to happier project teams, according to a new report by LiquidPlanner.

The 2017 State of Project Management in Manufacturing report found that 74 percent of the respondents who said they were highly satisfied with their existing project management methodology actually used a combination of methodologies.

At first glance, using multiple methodologies seems odd, especially in manufacturing organizations optimized with repeatable processes. The natural reaction is to respond “What’s wrong with my methodology?”

PMOs and process specialists spend months developing standard processes, methods, and templates to achieve predictable results. Believe it or not, the PMO doesn’t create a new template or a new process out of sadistic pleasure. Many PMOs seek to provide structure and guidance while letting project teams adjust and scale the methodology to the project.

Despite the amount of focus user group surveys, subject matter expert collaboration, and thoughtful process analysis, there will never be a single, perfect methodology for getting work done. It’s natural for project managers and teams to use a combination of processes and templates from multiple methodologies, such as waterfall, scrum, lean, and Six Sigma.

Here are six reasons why:

1. Methodology is not a silver bullet.

A methodology is merely a tool in a team’s toolkit to guide them to a successful outcome. The team delivers the project using methodology as a guideline. Effective teams still need strong leadership, project management, and clear communication to deliver. The best methodology in the world won’t help a struggling team from failing; it will help them fail according to the standards. This is why effective teams know to pick the best tool for the job, independent of prescribed methodologies.

I’ve participated in several project turnarounds where the project manager followed the methodology but failed to actually lead and manage the project.

One of my favorite projects successfully launched and delivered its objectives without a signed project charter. Methodology should be used to provide directional guidance and teams need to know how to adjust accordingly.

2. Projects don’t always follow a predictable path.

Projects are not a production assembly line. Methodologies are developed to provide guidance to produce a predictable result. However, few projects follow a predictable path.

When you’re working on a project, it’s likely that there is a methodology to follow. Yet, the journey to get there won’t always be a predictable journey. No two projects are the same; the people, environment, project constraints, and potential risks will be different.

Even my commute to work doesn’t follow a predictable path, and I drive it every day! Traffic, weather, and delays getting the kids into day care all impact my “project” to drive to work. If we can’t exactly predict when we’ll get into the office, how can we be expected to be 100 percent accurate on project end date six months out?

The key is to adapt and adjust. This also means tweaking the methodology.

3. People deliver projects, not methodologies.

We staff projects with talented people to leverage their professional experience and ensure project success.

I’ve met several certified PMPs, Black Belts, and Scrum Masters who shouldn’t ever lead or manage a project. People may be experts in a methodology, but if they lack the professional experience and subject matter context, the chance of project success is lower.

A few years back, a process quality assurance (PQA) analyst wrote me up as “out of compliance” because I wasn’t using a prescribed methodology template for meeting minutes. Instead, I used a mind mapping tool to capture the notes and actions and sent them out in a Word document. The team found the mind mapping format easier to follow and it actually lowered the administrative burden.

I understand the PQA analyst had a role to play, but it wasn’t in delivering the project.

4. Methodologies lag behind best practices and feedback loops.

The time it takes to introduce methodology changes, gain consensus, update documentation, and communicate the change doesn’t enable a project team to shift easily. Within the PMO, methodology changes can be launched quarterly to ensure best practices are incorporated and teams have time to learn and adjust. The lack of an updated methodology should not stop a team from implementing their own best practices.

Project teams need short feedback loops (an Agile principle) and should be encouraged to fail fast and experiment to find the best solution. Just because a methodology has a design phase, doesn’t mean the team can’t run small incremental proof of concepts to validate the design. As humans, we do this all the time and course correct.

5. External pressures and politics influence project decisions over process.

How many times have you presented a project launch date only to be told “not acceptable” or “go back and sharpen the pencil”?

You can incorporate every step of the methodology into a project schedule, but senior management’s requirements (or mandates) will always have an impact on the project.

After all, people are not machines. Politics play a role in project decisions and predictable outcomes. Unfortunately, teams that seek to skip “all that process stuff” end up with a troubled project that fails to deliver the intended result. Consequently, teams look to multiple approaches to solve project problems.

Project teams will always find a reason why a specific methodology won’t meet their needs because their project is “different”. Rather than constraining them to one methodology, allow them to pick the best tool for the job.

Of course, project governance still needs to be in place to ensure the project doesn’t “run off the track.” At the organization level, a portfolio manager or the PMO needs to ensure standard project milestones and checkpoints are being met regardless of the tools, templates or processes used in specific methodology. If project teams are encouraged to use the tools and processes that best fit their projects, the PMO and the project team need to align on the approach upfront.  Otherwise, some project teams will take this advice as not following a methodology at all.

The best way to strike a balance between methodology, delivery, and process-centric organizations is to tailor the methodology to the project and gain agreement. If I had done this one my past project, I may have avoided a non-compliance report from the quality assurance analyst!

After reviewing the 2017 State of Project Management in Manufacturing report, it doesn’t surprise me that more than half of respondents use a combination of methodologies. Those teams are selecting the right tool for the job. While that may not be 100 percent process compliant, it sure is smart!

Boost Your Productivity with Kanban Boards

The Productivity Problem

If a project team is struggling, a common reaction is to host a daily stand-up meeting. The term “stand-up” has a wide interpretation. Many of the stand-ups I’ve attended have turned into sit-downs because the meeting lasted for an hour rather than a few minutes.
In these stand-ups, project managers typically review a project schedule, assign tasks, and discuss an open list of issues. In Agile projects, the stand-up is optimized to focus on existing work in progress, next steps, and current roadblocks.

Regardless of Agile or non-Agile projects, I’ve seen team struggle with these questions:

  1. Who is working on what?
  2. What is the status of a given task or deliverable?
  3. Why is the task taking so long?
  4. Why isn’t a team member pulling his weight?
  5. Why isn’t that task finished?

Project managers apply tools and project schedules to help track the work and answer these questions. The Gantt chart is a useful tool to determine who is working on specific tasks and to track task status. Despite its utility, an exhaustive project schedule can be overwhelming for team members, stakeholders, and even project managers.

KANBAN

The Gantt chart can be overwhelming on large projects as team members want to know what to work on now instead of all the tasks across the project lifetime.

An alternative solution is to use a Kanban board,also know as the Card View in LiquidPlanner, to bring clarity and focus to project delivery.

Kanban Board

The Kanban solution has its roots in Japanese manufacturing and is associated with instruction cards being sent through the production assembly line. Software tools have enabled the Kanban solution to work across virtual teams and promote better collaboration and productivity.

KANBAN

With a Kanban board, tasks start in a To Do column and move across different column statuses until the work is Done. Kanban boards can be setup based on a business process or a team’s workflow. In the example above I use the following columns with my teams:

To Do – Unstarted tasks

  • In Progress – Active unfinished tasks
  • Blocked – Tasks that are blocked due to an issue
  • Customer Review – Tasks ready for customer review and approval
  • Done – Completed tasks

As team members work on each card, they move their tasks across the different columns. By focusing on the work in manageable chunks, the team can see the status of the work in process. If tasks are blocked, the team can discuss the issues and work together to either remove the blockage or defer the task to another time. If the task is rejected by the customer or there is a problem with the deliverable, the card is move back to the In Progress column for rework.

Kanban Benefits

The Kanban board offers several benefits to help improve productivity, including:

  • Transparency
  • Accountability
  • Improved communication
  • Identification of project bottlenecks
  • Defined focus on specific work
  • Drive for completion

While a project schedule is an excellent forecasting tool and identifies who is responsible for specific tasks, the Kanban board is more effective to drive productivity because of the transparency provided to the team. If a team member is assigned a task and hasn’t moved it to the In Progress column or isn’t demonstrating progress, the entire team is aware. Teams can break down the tasks into smaller cards so progress can be visibly observed.

By glancing at the Kanban board, the team knows the status. It improves communication visually, identifies delays, and provides a subset of tasks for team to focus on and deliver. As cards move from To-Do to Done, there is a sense of accomplishment and drive to complete the set of tasks within the given time period. The transparency is also motivating as each person knows the team is depending on them for specific tasks especially when the board is reviewed daily.

Using the Kanban Board in Your Daily Stand Up

In my Agile teams, reviewing the Kanban board at the daily stand-up was instrumental in communication and improving productivity. In prior Agile projects, I’ve been on teams where the group talks about their accomplishments, roadblocks, and upcoming tasks but they never tied the progress to the board. If you’re not implementing Agile principles, the Kanban board can still be useful by focusing on the key tasks within the next couple of weeks on the project schedule.

Each team member should be working on one and only one card on the Kanban board. Working on the highest priority card first and moving it to done allows the team to focus versus switching between multiple tasks. I’m not a fan of multitasking as the switching cost kills productivity. If the card can’t be progressed any further, it is moved to the blocked column and the next item on the board can be started.

Switching between Kanban and Traditional Planning

The Kanban board is one tool to help improve productivity and works well with a subset of tasks. “Sprints” work well with Kanban boards because the cards represent a subset of the overall schedule. Using software-based Kanban boards provides better communication with other stakeholders and still lowers the project managers administrative burden.

With LiquidPlanner, the team member can click on a specific card and update the remaining effort, update sub-tasks, and provide collaborate in threaded discussions. Project managers can use the Kanban board to manage week-long execution and then switch to the Gantt Chart view to assess the overall project progress.

KANBAN

Give Kanban a Try

Organizations have a never ending stream of work and teams are always looking for better ways to communicate, collaborate and deliver work better. Kanban provides the visibility to team progress and accountability. It also reinforces each person’s individual commitment to “move the ball forward” on card at a time.

Looking for more project management know-how? This eBook, How to Solve the Top 9 Project Management Challenges, provides practical tips and solutions to common project management challenges. You’ll also see how LiquidPlanner helps you meet your challenges—and turn them into opportunities!

How to Solve the Top 9 Project Management Challenges

Embracing Uncertainty in Software Projects

Uncertainty in software projects is inevitable. Use these three strategies to plan for it, address the risks and reap the rewards.

How long will it take?

A seemingly simple question that can become a project management nightmare to manage.

If you don’t give an answer, you’re viewed as incompetent and unable to estimate. (How could you NOT know? After all, you’re the project manager!) If you give a qualified answer, you risk being held to that original date despite the need to analyze requirements further, discuss with vendors and do proper project planning.

If you’re right and the project delivers on time, you’ll be heralded as a “someone who can deliver.” If you’re wrong, you’ll be regarded as “someone who can’t deliver.” The reality is you’re only as good as your last project and achieving a project date given months in advance is based on leadership, a drive for results, successfully managing expectations and let’s face it—luck!

Instead of relying on luck to deliver our projects, we need to change the way we communicate a project’s launch date and overall project costs.

Why Change?

In over 20 years of working in the software industry, the only thing I am certain about is uncertainty. No two projects are ever the same. Even if you manage similar projects, the requirements vary, the people and stakeholder needs change, the technology platforms adjust and the business has different priorities and project constraints. Due to these ever changing factors, software projects are full of uncertainty.

Good project managers will put risk management, change control and communication plans in place to manage scope and balance uncertainty. However, even better project managers look to embrace change and uncertainty while planning for it! One of the reason’s Agile software management practices have been so popular is they help teams embrace uncertainty.

The Cone of Uncertainty has been around since the 1950s but is popular among Agile teams to explain why a project’s effort and scope could be either 4 times or ¼ the size of the original estimate. Over time, the estimation variability decreases as the project team understand more about the requirements and the actual effort to deliver the project.

How to Embrace Uncertainty in Software Projects

Project teams can help embrace uncertainty by applying several approaches, including:

1. Embrace rolling planning and incremental funding.

Rolling planning helps project teams and customers refine estimates and make better decisions across the project lifecycle. Instead of funding an entire project, fund an Analysis phase or fund a few sprints to develop a valid proof of concept. Once the analysis or the proof of concept is completed, the team will have better estimates and can refine the project dates and the project costs.

This approach impacts traditional financial processes and budgeting as stakeholders need to request a budget first but can’t commit upfront to the end date and final deliverables. Transparency, incremental delivery and upfront communication on project unknowns is critical to clearing this hurdle.

2. Use ranged estimation versus single point estimates.

The LiquidPlanner blog has several articles highlighting the benefits of ranged estimates vs. single point estimates. Team members will find it easier to provide a high and low estimate vs. a single point estimate as it gives them some wiggle room for unknowns. As the task progresses, the same ranged estimate for remaining work is provided.

Embracing_Uncertainy_

The team can speak to status using these ranges and over time they will have greater confidence in a project’s expected finish date. Knowing a tool like LiquidPlanner provides this level of estimation at the project and task level is very helpful in clarifying uncertainty.

3. Deliver highest value features first.

Another Agile concept to manage the Cone of Uncertainty is to deliver higher value features first. In a past Kronos timekeeping implementation for a manufacturing organization, my team focused on delivering the core timekeeping features early in the project before moving on to the workforce management features. The plant wanted the plant floor workforce management features but there were a lot of union specific rules that needed to be sorted out before the package could be configured (i.e. uncertainty).

By delivering the timekeeping features first, we met a critical business need. The labor rules were so convoluted that the workforce management features were never implemented. Focusing on the features that provided the greatest return improved the project satisfaction. Worrying about a resource indicator that would never be activated due to business and technology issues was non-value add.

4. Communicate the unknowns early.

Successful project management is based on trust, collaboration and frequent communication on the project health. By communicating the unknowns early and providing options to address uncertainty, both stakeholders have an equal opportunity to manage the risk affecting project timelines and deliverables. The problems start when the client and the delivery team fail to maintain trust and communication.

Project teams will always have challenges managing the project triangle of scope, cost and time. At the start of a project, uncertainty is at its largest and teams need to avoid making promises they can’t keep. A better approach is to work incrementally, provide frequent feedback and use effective tools to help forecast end dates based on actual data instead of emotion.

Uncertainty will always exist. The best approach is to embrace it rather than ignore it.

Managing projects is hard work. You need to have a wide range of knowledge and skills—from tracking schedules and satisfying stakeholders to juggling people and technical skills. This eBook, How to Solve the Top 9 Project Management Challenges, provides practical tips and solutions to common project management challenges. You’ll also see how LiquidPlanner helps you meet your challenges—and turn them into opportunities!

How to Solve the Top 9 Project Management Challenges

How to Scale Methodology for Your IT Project

project methodology

If you’ve worked for an organization of any size delivering software projects, you’ll eventually be asked to follow a methodology. In small organizations, it could be a common set of steps that are “light and nimble.” As the organization grows, more steps are added, additional teams are consulted and before long—you’re got a full-fledged methodology to manage.

Methodology is a tool, not a torture device designed to inhibit project teams. Methodology provides guidance across an IT organization in order to successfully deliver projects. As much as project managers like to control all decision-making in a project, there are times when IT project managers need to engage other IT teams like Architecture or IT Security. A few examples include:

  • Launching a new website
  • Working with systems that contain confidential or personally identifiable data
  • Ascertaining whether or not the server can handle all the traffic

In the following examples, team leaders probably should check with IT Security, Architecture and the Infrastructure teams while moving through a project. If you’re new to the organization, a standard methodology helps guide you on how to engage these teams to get the information you need, and give them a heads up about what’s going on that affects other departments.

When Teams Resist a Methodology

Here’s an example that might sound familiar: A project management office (PMO) or senior leader publishes standard steps, establishes checkpoints (tollgates) and project audits to ensure teams are compliant with the process. At the same time, various project teams squirm to explain why their project is different and how the methodology doesn’t fit. Agile project teams start waving the “Hey we’re Agile” flag and want the team to decide on the right processes and tools for the project, instead of a third party organization making process decisions.

Successful organizations will scale the methodology based on the complexity of the project. Methodology teams produce methodology frameworks to ensure teams follow a consistent process that integrates all IT and business stakeholders. However, projects differ in scope and complexity so the methodology should adjust accordingly.

The best way to align the methodology with the delivery team is to tailor the methodology to fit the project. Much like tailoring a suit, the process leadership and project teams work together to apply the processes that best fit the project.

Below are six steps your teams can take to successfully scale your methodology:

Step 1: Define the Methodology

If the organization is well defined, there should be a published methodology with all the processes, activities and templates needed in order to deliver a project. Some organizations publish a loosely structured framework and others have perspective steps based on the type of software project—Waterfall, Agile, a combination; Software As a Service (SaaS) or Commercial Off The Shelf (COTS) packages.

Step 2: Identify mandatory and optional components

Review each process step, deliverable and template. The methodology will outline optional steps and the ones that are mandatory. With an increased focus on security and cloud-hosting, security scans and infrastructure assessments should be mandatory.

Step 3: Develop a tailoring process

When project teams implement projects, they want to know which processes are required and how to adjust the methodology to fit the project. Developing and communicating a tailoring process will help your team understand how to scale the methodology. Below is a generic tailoring process that includes the project manager, the PMO and any shared service team like security, architecture and infrastructure. If your organization doesn’t have a formal PMO, I’m sure there is someone overlooking overall quality and ensuring common processes are being followed.

project tailoring

Step 4: Tailor the Project

By reviewing the processes and deliverables upfront required to deliver the project, everyone has a common understanding of expectations. If a process step doesn’t make sense, remove it but at least get agreement from the key stakeholders in the IT organization.

If you’re deploying a new Internet facing website, you’re better off making the security scan or IT security review mandatory versus optional. However, if you’re delivering a second release of an existing software application, the project charter is likely optional.

Step 5: Execute and Adjust

Based on the tailoring document, the project will create the appropriate deliverables. During project execution, if a step no longer applies or if a step needs to be added, simply adjust the tailoring decision document and review with the process owners. In formal gate reviews, the tailoring decision document confirms that the correct processes are being applied, so it’s important to keep that document updated.

Step 6: At the end of the project, review and refine the methodology

It’s important that the project team provides feedback on the process; regular feedback helps improve the methodology over time. No one wants to be accused of “sitting in an ivory tower” and dictating process without understanding the impact. For example, the project team might find redundant processes or identify improvements to project templates. Over time, similar types of project tailoring will emerge and the organization can publish these tailoring decision documents as scaled versions of the methodology. Your organization will find the methodology will scale for outsourced IT projects, infrastructure projects, COTS implementations, business process outsourcing, Agile and traditional waterfall projects.

Methodology is a tool

Remember, methodology is a tool to help align all the IT teams and their respective processes. One tool isn’t a fit for every project so adjustments need to be made to ensure project teams are delivering in the right direction. Security, architecture, IT compliance and infrastructure teams all want projects to succeed and they define processes to ensure success.

The PMO or a senior IT leader’s job is to help standardize and communicate these processes as projects execute. Project teams can still be reluctant to follow a singular prescribed process. The best way to scale your project for success is to scale your methodology to fit the project and then agree to all decisions up front.  Remember: establishing a methodology, especially one that can flex to the changing needs of teams, is a tool to help teams deliver excellence.

Addressing, selecting and getting adoption on a methodology is one of the challenges to project management. To get more solutions to classic PM issues, download our eBook, “How to Solve the Top 9 Project Management Challenges.”

How to Solve the Top 9 Project Management Challenges

Project Manager vs. Program Manager: A Side-by-Side Comparison

project management software

Project Manager . . . Program Manager. Most of us have met one or the other, and many of us have wondered: What’s the difference?  It’s easy to get confused because in some organizations program managers do work that looks a lot like what program managers do. Also, the names are so similar it’s hard to separate their meaning. And then there’s the question—does it matter? Yes, it does!

If you’ve ever been curious as a project team member to know what the program manager down the hall is doing; or you’re someone who wants the next challenge in your project management career, I’m going to lay out the differences here. For starters, the fundamentals of good project management build the foundation for making a successful transition into program management. So, let’s start with the basics.

What exactly is a program?

I’ve seen this word misused many times. This happens when a team member is offered the title of “program manager” where the scope is only confined to one project. If I dust off my PMI standard, we know that a project is a “temporary endeavor used to create a unique product or service.” A program is “a collection of related projects managed in a coordinated way to obtain benefits and controls not available from managing them individually.” It might seem like running a program is similar to running a bunch of projects, but there are several key differences between how a project and program moves through the project lifecycle.

Here, I’ve categorized some of these differences across the initiation, planning, execution and close lifecycle steps.

Project vs. Program Initiation

Here are a few key tasks that distinguish programs from projects. Project and program sponsors are critical, although the funding cycle, organization structure and sponsorship can take longer.

Project Tasks – Initiation

Program Tasks – Initiation

● Identify the project sponsor.

● Allocate budget.

● Identify key stakeholders.

● Assign a project manager.

● Validate the program business case.

● Identify the program management structure.

● Identity the program sponsors.

● Review funding sources.

● Assign a program manager.

Projects can be funded and initiated faster than most programs primarily since budget, sponsorship and stakeholders are smaller than most programs. A project typically exists within one team or an organizational boundary. A program will often cross multiple organizations, and this has an impact on stakeholders, sponsors, funding sources and even assigning the right program manager.

In a project, the project manager is primarily responsible for the scope, cost and timeline. In a program, the program manager will also staff a project management office (PMO) to help manage program scope, costs and overall timeline. Since it can take longer to initiate a program after its conception, the organization might have to validate the business case to ensure the program goals are still worth pursuing.

Project vs Program Management Planning

Every effort has a planning phase. A program will rely more on a rolling plan, as multi-year programs will need to adjust their plans as the business changes. Scope, schedule and resources all apply to both programs and projects although the planning is conducted at different levels. Project managers are used to tracking tasks against a project schedule. Program managers need to track milestones against a program level schedule.

Project Tasks – Planning

Program Tasks – Planning

● Develop the project management plan.

● Define project scope.

● Define the schedule.

● Define the resources.

● Define the detailed budget.

● Develop the program management plan.

● Define the program scope.

● Define the program schedule.

● Define the detailed program budget.

I’ve been on other programs where teams struggled with developing integrated project schedules, mainly due to the tool they’re using (or aren’t). The end result involved team members trying to make the project schedule mechanics work when they should’ve been focused on the milestones. In a program, communication across teams and milestone management are more important than tracking individual project tasks. Let the project managers manage their work and let the program management team manage across the work streams.

Project vs. Program Execution

Successful execution is all in the details! Both projects and programs have a lot of details to manage, including the deliverables, schedules, and issues and risks. Below are a few of the key distinctions.

Project Tasks – Execution

Program Tasks – Execution

● Manage the project schedule.

● Manage the project budget.

● Manage issues and risks.

● Manage communication.

● Manage scope and change.

● Manage the team.

● Manage quality.

● Manage project procurement.

● Manage the program milestones.

● Manage the program budget.

● Manage program issues and risks.

● Manage program communication.

● Manage program scope and change.

● Manage human resources.

● Manage quality.

● Manage program procurement.

● Apply stakeholder management.

● Apply program governance.

 

 

 

In the PMBOK, integration management is the set of project management processes used to make sure that projects are properly coordinated. Project plans, project execution and change control techniques are all used to steer each project in the right direction.

One of the key roles of the program manager is to ensure that all the work streams connect together. Project teams have a more focused view on the work that comprises a project; the program manager has a broad view of all the work streams. This role needs to see how all the “gives and gets” integrate across the timelines. As a program manager, it’s also important to understand the major dependencies across project teams. You don’t necessarily need to integrate every project schedule and every task as a program manager, but you should develop a program-level plan that integrates the major milestones.

I was once involved in a digital marketing program, where the IT team was delivering a content management system with different components. The global marketing team would develop different sites based on the components delivered. As the program unfolded, both European and U.S. marketing teams needed to know when specific components would be delivered by the IT team. If IT was late, the site development was impacted.

Every project has issues and risks. As the program manager, you don’t need to manage or even know about all of them. The program manager needs to know about the program-level issues and risks but doesn’t need to know about every risk with each project. The guideline I use is to focus on issues that impact a milestone. Otherwise, you’ll be reviewing every issue and risk during program status meetings, and that would take hours.

All project-level issues and risks should be available for the program manager to review. Have a log for common risks and issues, so they can be categorized.

Project vs. Program Closure

The closure phase is the last phase where the project or program manager formally closes the project.

Project Tasks – Closure

Program Tasks – Closure

● Conduct project conclusion and lessons learned.

● Transition solution to operations team.

● Confirm project success or failure.

● Provide performance feedback.

● Disperse resources.

● Close financial contracts.

● Archive project documents.

● Conduct program conclusion and lessons learned meeting with the PMO or project lead.

● Transition solution to multiple operations teams.

● Provide performance feedback on PMO/project lead resources.

● Disperse PMO/project lead.

● Close any financial contracts.

● Archive program documents.

Each project in a program will have its own set of lessons learned; however, the program PMO or project lead will also a set of lessons learned. Project managers will provide performance feedback to respective resource managers; the program manager might also provide feedback on the team that formed the PMO. In an IT program, there can be multiple operational groups that need to support the systems delivered—and more teams requires more communication. Financial close out and the archiving of documents is similar across both efforts, except the size could differ in a program.

Program management is an important role in a project-driven organization. It’s also an exciting challenge in a project manager’s career. As you familiarize yourself with the difference between project management and program management, and even consider program manager as the next step in your career, it’s important to identify exactly how these roles differ. Programs are more complex and require more political awareness than the average project. However, the satisfaction from delivering across complex organizations is a rewarding one!

Here’s something project and program managers have in common: the need for a reliable project management tool! Is yours up to snuff? Take our Project Management Health Check, a 9-question multiple-choice assessment of your project management process.  

Take the assessment!

How to Make Your Project Schedule Work for You

project schedule

At a recent conference, I was asked, “Why do project managers hate schedules?”

I had to think about this for a while because I don’t think project managers hate schedules. I think what project managers don’t like is the administrative work required to maintain it.  A detailed and well thought out project schedule is my #1 tool to use when managing a project.  Without a schedule, I’d get lost trying to track work and herd all the cats.

I’ve worked with other PMs who are not as adamant about having a detailed project schedule, and I’ve seen quite a few executive-level Gantt charts that lack supporting detail.  When I probe further on why a detailed schedule doesn’t exist, the responses include:

  • “I manage with my gut.”
  • “I rely on the vendor since it’s their responsibility.”
  • “I’ve got two other projects running, do you think I have time for all that?”

These responses are indicators of an incoming train wreck. With these project managers, they often present project status as a state of being “where we are” without considering the “where we should be” part of the lifecycle.

5 Signs Your Project Schedule Isn’t Working for You

When smart, capable PMs turn to unreliable and freewheeling methods of project management, it’s a good sign that they’re stuck using 20-year-old project management tools. These inflexible legacy platforms don’t work for projects that require real-time collaboration and communication, or automated scheduling. You know you’re stuck in the past if any of these tell-tale signs ring true:

  1. The project schedule is built just once by the project manager—at the beginning of the project.
  2. The project schedule lacks accurate updates including completed tasks and slipped tasks.
  3. The project schedule only exists in a Gantt chart view to pass a toll gate presentation.
  4. You have to update status on every task in the project schedule when something changes.
  5. You’re always being asked for the latest copy of the project schedule (and you don’t have it).

I’ve learned to ask “Why” as a way to discover the root cause of why PMs resist using their scheduling tools. The reasons often involve:

  • “The tool is too complex.”
  • “It takes too much time to update the schedule.”
  • “I can’t get status from everybody on time.”
  • “The plan keeps changing.”

A project schedule will always change, and your team needs to make the necessary adjustments to meet the commitment date.  However, keeping up with the administrative burden using traditional tools only perpetuates the schedule management problem.

5 Ways to Make a Project Schedule Work for You

  1. Incorporate schedule metrics into status reporting to reinforce measuring what you manage.
  2. Establish a weekly review of schedule performance to ensure that everyone understands upcoming tasks, and can provide updates to in-progress and behind schedule tasks.
  3. Develop views or filters to quickly identify team member tasks.
  4. Set the expectation that task status is due at a specific time each week. Even better, use a tool that allows real-time updates based on hours actually worked.
  5. Publish the schedule to a collaboration solution that allows everyone to view the latest updates to the schedule.

Building and managing a project schedule doesn’t have to be overly cumbersome. The schedule is a useful tool to forecast end dates and keep teams on track.  Even with online project management tools, the schedule is only as reliable as the data provided by the team. And, by incorporating schedule metrics and weekly reviews into the project cadence, the team and your stakeholders will have a better understanding of the changes in the project schedule.

The project schedule will always fluctuate and project managers need to accommodate changes.  If you’re using outdated tools, then you’ll want to consider current alternatives that make the project schedule work for you.  The schedule will help you manage the commitment dates, and that’s a growing necessity in an increasingly competitive business environment. And, as we all know, as the commitment dates slips, so does your credibility.

Are you curious about your PM process could be better? We’ve got just the tool for you! This 9-question multiple-choice quiz will diagnose the health of your project management tool and/or process.  

Take the quiz!

The Day I Gave Up Updating the Project Schedule: A Story

project schedule

I remember the day I gave up maintaining the project schedule. It all took place a few years ago at a little Thai food restaurant in Dearborn, Michigan.

The best Thai food place in Metro Detroit is hands down Bangkok 96 on Telegraph Road and Michigan Avenue. The food is so good that if you don’t get to the restaurant by 10:45 a.m. you won’t get a seat when the doors open at 11. To complicate matters, it was a Friday (a.k.a., Good Soup Day) where they serve one of the best hot and sour soups I’ve ever had.

I was meeting a professional colleague of mine, Darren. Bangkok 96 was our go-to restaurant where we could catch up and talk about our respective jobs and the projects we were working on. Just as my Gang Gai chicken was being served, I launched into my dread of my upcoming afternoon: chasing down task statuses from team members in order to update the schedule before week’s end. I ran through the frustrating process:

“I have to get a hold of my development team to do the usual updates. I also need to get a hold of Jerry and his infrastructure guys to confirm that the servers are being stood up in time. It’s a pain trying to get a status from all these individuals, who also have their own schedules. I get it. Everyone is busy but how hard is it to let me know how much work is remaining or if the target date is still on track?”

Darren nodded as he stuffed a forkful of Kraw Time Prik Thai into his mouth.

“When do you host your schedule update meeting with the team?” I asked.

“I don’t,” he answered.

“What do you mean you don’t? You’ve got a project schedule to maintain, right?” I stuffed a forkful of Gang Gai into the complimentary Shrimp chips which makes a fantastic mini Thai taco.

“Yep,” he replied.

“Ok Obi-Wan, expand.” I was about to extol the importance of updating Microsoft Project.

“Well I don’t maintain the project schedule, the team does,” Darren explained. “A few months ago, we invested in a cloud-based, collaborative project management tool. It’s fantastic! Now, I don’t waste my time following up with every team member. Everyone on the team tracks their time each week, and we bill that time, and manage it, against the activities in the project schedule. We input the amount of hours we spend on work on a project, and how many hours are left and the tools does all the updating.”

“Yeah but you have to build the schedule, right?” This was sounding too good to be true. “Isn’t it a pain trying to detail all the tasks and delegate them out?”

“Nope. The entire team builds the schedule—together,” Darren continued. “I develop a high-level breakdown of all the stuff we need to deliver and the team develops their own tasks within in the tool. I found we actually get better estimates and buy-in from the developers because they create the tasks and are held accountable for the estimates they provide.”

“Do you still have to get through a lot of email?” There had to be a catch.

“Not really,” he shrugged. “We even use the tool to host our discussions on the assigned tasks. On each task in the schedule, team members can attach documents, leave comments or have discussions within the tool itself. We encourage the team to maintain conversations in the tool rather than get into a game of email ping-pong.” Darren explained.

I knew the game of email ping-pong all too well. Heck, I’ve even been guilty of pushing off work because I “sent you an email” asking for clarification.

“We even took document management to the next level,” Darren continued. “We used to send Excel spreadsheets and Word documents via email as team members didn’t always keep the most up-to-date documents on the Sharepoint site. Now I tell the team I won’t look at any file they email me. They need to point me to the URL where the file is stored in our tool. It’s usually found within the assigned task and that is the version we keep maintained.”

I was amazed at his efficiency. By leveraging a collaboration solution, he escaped the schedule management purgatory that can occupy painstaking hours of a project manager’s time. I loved the idea of having the team build the schedule in the tool and then giving the project manager room to “tweak” and adjust as necessary.

“You have to give the name of this tool. I’m going to check it out after lunch,” I said as we received our bill. “But what do you do with all your time if you’re not updating the schedule and chasing down status?” I was joking—sort of.

His reply was a simple one.

“Lead. Isn’t that what project managers should do?”

Lunch was on me that day. That afternoon, I signed up for my free trial.

What’s almost as good as a Project Management Process eye-opener over Gang Gai chicken? A Project Management Health Check Tool. This 9-question multiple choice quiz will tell you how effective your PM methods are, and will follow up with solutions and a new tool that can save you and your team hours on status-chasing.

Take the quiz

Why You Should Use Predictive Scheduling for Your Projects

I had a hallway conversation with my colleague about the best way to manage a project schedule. My colleague admitted to developing a pretty Gantt chart at the beginning of the project because executives like pictures. He also admitted that he wasn’t sure how accurate or up-to-date the schedule was with reality. When I asked how does he know whether the project is on track, he replied, “I manage with my gut.”

predictive scheduling

I pushed him a little more on this point because I can’t do my job properly without a valid project schedule, and believe:

“If you’re gonna manage it, you need to measure it.”

I’ve known others who have succeeded by managing with their gut but I still prefer the data that tells me the project schedule really is on track. His response to my “measure what you manage” belief was “I’d do more tracking and realistic scheduling if I didn’t have 10 other fires to put out.” My response to this is: If you build a realistic and predictive project schedule, you won’t have so many fires to attend to, since a predictive schedule provides greater reliability. Fewer surprises.

Let’s take a closer look.

Predictive vs pick-a-day scheduling

Predictive scheduling is the scheduling technique that relies on predecessors and resource constraints to forecast meaningful task start and end dates. If you’ve ever built a schedule using a predecessor column and linked tasks, then you’ve taken your first step in developing a predictive schedule.

In predictive scheduling, the project start and finish dates are dynamic. They adjust based on actual project progress and are compared against project commitment dates or a project baseline. Predictive schedules require a little more time to create since you’re analyzing the dependencies and resource commitments. In a predictive schedule, you actually want the dates to adjust based on the resource availability and task dependencies. The benefit is a more realistic project schedule because it models the “real world” by including resource constraints, resource availability and dependent tasks

Conversely, pick-a-date scheduling (i.e. fixed date scheduling without logical dependencies) does not take any of the previous criteria into consideration. Pick-a-date scheduling is exactly what it sounds like—selecting a singular. The problem here is that if a task is dependent upon another task or if a preceding task slips, there’s no clear way to identify an impact on the project schedule.

Where does pick-a-date scheduling fit?

Pick-a-date scheduling is often driven by clients and project stakeholders who have likely already picked a date before the project has even started. This is usually driven by a business need or some previously communicated delivery date. The challenge for the project manager is to balance these expectations with the realistic effort to deliver the project on-time, within budget and within scope. For portfolio planning purposes, I’ll pick a date at the three-month or six-month level. These dates are used to provide a rough order of magnitude for top-down budget planning. If I have more time and more details, I’ll provide more realistic details with a predictive schedule.

However—there’s an important difference between the two:

  • Pick-a-date scheduling is used to communicate a goal or a desired delivery date.
  • Predictive scheduling should be used to validate this top-level decided date and confirm if the desired date is viable.

If you’re executing a project schedule without reflecting reality, you’re at best guessing and hoping you’re right.

You can probably guess which method I prefer.

How a predictive schedule helps manage teams

A predictive schedule helps manage project teams in the following ways:

  1. All team members know the impact to their work.
  2. You have greater confidence knowing if you’re going to meet the project launch date.
  3. The task start and finish dates adjust based on team performance.
  4. The project manager can accurately forecast completion dates without having to guess if a team member is available or if a task can start on time.

Let’s look a little closer at these predictive schedule benefits:

  • All team members know the impact to their work

Everyone wants to know that their work matters. In a predictive schedule, if a single task is late and impacts another task, all the team members can see the shift in their own dates. With the pick-a-date method, your team members don’t necessarily know if your task will impact their work or not because there are no dependencies. A predictive schedule incorporates real world constraints—it shows resource availability, task dependencies and resource allocation to ensure that the schedule reflects real world execution.

  • Greater confidence

A predictive schedule helps the team communicate with greater confidence to meet project commitments. As a project manager, you can examine the project’s critical path and quickly assess if the end date adjusts. If a task slips, the team not only knows the impact but the person who is accountable can help realign the deliver date.

  • Automatic date adjustment

If you ever planned a complex schedule in spreadsheet, then you know how difficult it is to keep the dates updated as well as forecast future dates. In smaller projects, a spreadsheet check list is fine but in large projects, you need a predictive schedule to forecast date changes. The main benefit is the time saved administering the schedule which provides more time to communicate with the team. Some folks new to predictive scheduling may be surprised when the date shifts, but that’s the entire point of building a dynamic and predictive schedule. The dates should adjust automatically based on task performance.

It’s your job to make sure that the finish dates align to the original commitment date.

Forecast completion dates without guessing

If you’re not using a predictive schedule, you’re simply guessing at dates without considering to resource constraints and task dependencies. With a pick-a-date schedule, you’ll find yourself pushing team members to complete late and current tasks all at the same time. This is unrealistic and increases stress rather than increase productivity.

With predictive scheduling, your team will do great work and forge lasting relationships because of the strength of working toward realistic dates and assignments. As the PM, you’ll lead a team to great heights by determining realistic dates based on logic instead of guessing.

Predictive scheduling helps teams navigate project uncertainty like superstars. To learn more, download our whitepaper, Tackling Uncertainty in IT Projects.

LiquidPlanner tackling uncertainty