Creating Achievable Project Goals

Creating Achievable Project Goals

Photo by UK Black Tech on Unsplash

Want to make project goals achievable? Start by making sure they’re clearly articulated and supported by key stakeholders. That’s no guarantee though because other conditions can affect their achievability. Here are actions to help ensure your project goals are reasonable and motivate your project team.

  • Include training and experimentation tasks in your plan. You will attract the best team members if your project offers learning opportunities. Include training and the chance to practice new skills with some experimentation in your project plan. This expands team members’ understanding. New skills also pique team member interest in project goals. Businesses must innovate to remain competitive. So, treating projects as learning opportunities in addition to enhancing business capabilities means more value that your projects can deliver to stakeholders.
  • Develop success measurement approaches before creating success criteria. A common mistake made by project managers is to define success criteria without understanding how those criteria will be measured. For example, some criteria can be assessed only with subjective measures. This often causes conflict instead of uniting the organization around success. Create the measurement process first, then determine what result will be considered success. Your success criteria will be meaningful and allow you to track your degree of success.
  • Focus on business processes, not tools or IT systems. Project staff are more likely to understand project goals when they’re tied to existing business processes. Focus on the new or revised business process objectives. This helps team members understand the direction they need to take to meet project goals. Difficulties occur when goals focus on tools. For example, the goal “Implement a new warehouse security software system” leaves out the problem that needs to be corrected, or what opportunity the business wants to achieve. 
  • Set practical timelines. Project team members are more likely to support practical, non-arbitrary deadlines. A practical deadline means the timeframe reflects durations proven achievable in past projects. However, a tight deadline for legitimate reasons can be considered practical if management supports new approaches to help meet the deadline. Tight, but practical timelines require motivated teams, so explain the rationale to them to gain their support. (Think Apollo 11 landing on the moon prior to the end of the decade!)

What else do you do to create achievable goals and obtain support for them? Share with us in the comments section.

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

Coming Up

Great Meetings Build Great Teams

Although great meetings won’t guarantee project success, poorly run meetings could lead to project problems. In this Office Hours broadcast, I’ll be talking with Jim Stewart, PMP and Rich Malzman, PMP about how to keep your necessary meetings from becoming necessary evils. 

Find out why you should create a project plan for a meeting, how to handle people who behave differently in meetings. Learn about the science of meetings and how to use it. Listen to lessons learned from real-life meeting experiences. 

Join us for a fun and informative session. (Bring your questions for a chance to win a complimentary ebook of Great Meetings Build Great Teams. Click here to sign up: https://www.linkedin.com/events/7079138489325268992

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 40,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Organizational Factors to Consider in Project Requirements

Organizational Factors to Consider in Project Requirements

The Jopwell Collection on Unsplash

Business needs aren’t the only things you need to look at when developing project requirements. Organizational customs and characteristics as well as the regulatory environment within an industry also come into play. Here are other elements to analyze as you work on project requirements. 

  • Language and process variation across the organization. To create requirements that benefit everyone, you need to look at and address variations in processes and terminology. Smaller organizations often don’t document processes. As a result, different people may perform the same job in different ways. They also might not use the same terms for describing events and process steps. To overcome these issues, plan to interview multiple people. You also need to do this in large organizations, but for different reasons. Large organizations might have process variations based on local laws and local habits. 
  • The regulatory environment. Many industries, such as banking and healthcare, have regulatory obligations, which will affect project requirements. However, there is a key point to identify with regulatory requirements: Do the regulations dictate processes that must be used to generate an outcome, or is it just the outcome that’s regulated? This distinction has a significant effect on project requirements. For example, investment bankers might need to produce a report on the changes they make to their client’s investments. How that report is produced might not be regulated, as long as the outcome is accurate and meets regulatory requirements. 
  • Decision-making customs. How requirements are developed will differ within organizations that use consensus-based decision-making versus hierarchical decision-making. (For a funny example of dysfunctional hierarchical decision-making, check out this Mr. Show sketch video.) The difference is sometimes referred to as “power distance.” In other words, the organizational distance between decision makers and non-management stakeholders. Let’s say a second-level manager in a hierarchical organization approves any requirements. However, the requirements should be more reviewed by others before that approval. For example, first-level managers and the “worker-bees” (non-management personnel) that report to them need to examine and provide feedback on the requirements.

Things are different with consensus-based decision making. You need to consult more people to ensure requirements are accepted. In most cases, you need to involve teams that feed into or receive information from a process. With consensus decision-making, that audiences that review requirements are more horizontal than vertical, such as across departments or business units.

  • add this link behind the text “sketch video” https://www.youtube.com/watch?v=KyocQT4Vn2g
  • Degree of individual empowerment. Some organizations are very rigid about their processes. Employees must follow process to the letter, regardless of the circumstances. Other companies empower their employees to be more agile. Companies with empowered employees focus on outcomes over compliance. So, in the occasional case when a business process won’t produce the intended outcome, employees can vary standard processes. When writing requirements, understand the degree of empowerment employees have. If rigid compliance to process is in place, requirements should have restrictions around what people can execute. When embracing more agility, the ability to diverge from process standards should be part of the requirements.
  • The risk tolerance of the organization. When organizations are risk-averse, people might be uncomfortable with change, so they avoid proposing big changes that could be needed to meet business objectives. In this environment, persistence is helpful. To expand possibilities, ask stakeholders for options beyond conservative requirements that they request. The project team can then figure out if those requirements can be delivered within an acceptable level of risk. The benefit of doing this is to increase the value the project can deliver to stakeholders.

Do you have tips or questions about developing better requirements? Add them to the comments section.

For more about requirements, check out Angela Wick’s Requirements Elicitation and Analysis course.

Coming Up

Watch for more Office Hours broadcasts in July!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 38,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Are You an Overloaded Project Manager?

Are You an Overloaded Project Manager?

Photo by Christina @ wocintechchat.com on Unsplash

Project managers usually manage more than one project at a time, which means they provide more value to their organization. But problems can arise when a project manager has too much work to do.  The Project Management Institute’s Code of Ethics and Professional Conduct recommends that project managers be honest and work within their skills and capabilities. So, if your workload is excessive, you should ask for help. Here are some indications that you are or could soon be overloaded.

  • Your PM workload adds up to more than your expected work hours in any given timeframe. A rough estimate of your PM workload is to calculate the total hours for all project work tasks (non-project-management) and then add 15% for project management. For instance, if the total hours for work tasks is 100 hours, 15 project management hours is a reasonable estimate. When you manage multiple projects, add up the 15% PM estimates from each project. If the combined total for any timeframe exceeds your expected work hours, there is a risk of overload.

     project hours.jpg

    Project manager workload with possible overload

  • Stakeholders feel ignored. Stakeholder management is an important activity for project managers. An early indicator of PM overload is key stakeholders saying they don’t know what’s happening on a project or say they are frustrated by their questions not being addressed. If this happens, look at the type of issues stakeholders raise and the complexity of your projects. Overly complex projects, even small ones, could require more time than the 15% rule of thumb suggests, which could cause PM overload.
  • Schedules aren’t updated. As a project manager, maintaining the project schedule is a fundamental, administrative project management task. As tasks are completed, you record progress and re-estimate project cost and completion time. If you’re overloaded, schedule updates are one of the first things that drops off your radar, even if you have a scheduling person to help you. If you don’t have time to update the schedule, it is time to ask to have some of your projects to be reassigned or to get some additional help.
  • Team synergy problems arise. Project managers need to ensure their team members are on board and working well together. They must understand their role, the responsibilities of other team members, and the relationships between deliverables. If this understanding breaks down, a PM typically notices these problems quickly. If not, you haven’t been paying attention to your team’s status, which could be due to your being overloaded.
  • Technical project issues arise and aren’t addressed. If you haven’t addressed technical issues that arose, this could be an indication of project manager overload. However, it can also mean you don’t have enough training or that you don’t have access to an experienced technical team member to address those issues. If that’s the case, you should ask for a technical resource to help you (because by that time training will take too long). 

Note: If you are supervising project managers, you can use these overload indicators to identify project managers that need help or to reassign projects to others.

What do you look for to determine whether you or one of your project managers is overloaded? Share with us in the comments section.

For more about project management effort, check out my Project Management Foundations course.

Coming Up

Keep on the lookout for more Office Hours broadcasts in July!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 39,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

How to Leverage Organizational Change Management in Your Projects

How to Leverage Organizational Change Management in Your Projects

Photo by CoWomen on Unsplash

Projects drive change, so good change management is important for delivering project objectives successfully. Integrating project management with organizational change management means  that you manage the development of deliverables while also  making sure that stakeholders can use those deliverables to deliver business value. Here’s are some tips for  leveraging change management in your project plans.

  • Assess your organization’s change readiness. Success won’t be achieved if your organization isn’t equipped to handle the change that your project will introduce. One challenge for successful change is too few internal experts to both run the business and participate in the project rollout. Another challenge is change fatigue, which ambitious management teams often ignore. Your change manager should conduct a readiness study to ensure expertise is available and change fatigue won’t hamper your project.
  • Appoint technical experts as change agents. The change agent role often falls to the best communicators in the organization. This makes sense, because communication from and feedback to the project team is vital. However, technical experts have some advantages as change agents. Their technical expertise gives them influence. When they share their rationale for a change publicly, it carries weight with employees and management. If public speaking isn’t their strong suit, ask your change manager to help construct and deliver the technical expert’s message.
  • Leverage milestones. Like a project, change management is a journey. And just like a project, change management plans should include milestones to indicate progress. Change models such as ADKAR* have natural points for milestones, which you can include in your project plans. Emphasize the importance of reaching those milestones to make progress in your project schedule.
  • Deploy specific change-readiness criteria. Completion criteria are important for the change components of your plan. Tailor completion criteria (or readiness criteria) for different stakeholder groups who must absorb different types of change. Overall criteria like “the organization is ready” aren’t enough. Look at what each stakeholder group that’s absorbing change must accomplish. And create specific change readiness criteria for each group. Discuss the importance of meeting these criteria with management in advance. This will make it less likely for management to push out a solution without proper change readiness.

For more about change management models, check out the ADKAR site.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 38,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________