Skip to main content

Tag: Stakeholder

PMTimes_May03_2023

Streamlining Project Communication: A Guide to Simplifying Technical Jargon in Reports

Reading a document and struggling to understand the information presented is a common experience, especially in specialized fields like Information Technology (IT). As a project management consultant specializing in IT reporting, I frequently encounter industry jargon from Subject Matter Experts (SMEs). My role is to ensure these reports are clear and comprehensible for their intended audience. This article discusses my approach to simplifying reports by eliminating technical jargon, providing real-life examples, and offering practical tools and resources.

In project management, reports are documents that record and convey information to a specific audience. Since reports are vital communication tools, it is crucial to adhere to specific guidelines to ensure effectiveness in communicating information. By following these criteria, project managers can support informed decision-making and promote overall project success.

 

  1. Clarity: Ensuring clarity in reports is paramount, as it allows readers to easily comprehend the information presented. To achieve this, I use simple language and avoid jargon or technical terms that may confuse readers. When introducing new ideas or concepts, I aim to present them in their simplest form. For example, in a software development project report, instead of writing “The system’s API will employ OAuth 2.0 protocol for authentication,” opt for a more accessible explanation, such as “The system will use a widely-accepted, secure method to confirm user identity.” In another instance, instead of using the term “bandwidth” to describe available resources, use “capacity” or “availability.
  2. Accuracy: Accurate and reliable data is the backbone of any effective report. Reports should draw information from credible sources and avoid biases or errors that may distort the information. For example, when discussing a construction project’s progress, rather than stating, “The construction is ahead of schedule,” provide specific, verifiable data: “The construction is 10% ahead of schedule, as confirmed by the project’s timeline and the latest site inspection.
  3. Relevance: Reports must be tailored to the intended audience, providing information that aligns with their needs and interests. If writing a report for a project’s executive sponsors for instance, focus on high-level insights, financial data, and overall progress. In contrast, a report for a project team may require more detailed information about individual tasks, deadlines, and technical challenges.
  4. Timeliness: Reports should be current and up to date, reflecting the most recent information available. For example, if submitting a monthly financial report for a project, ensure that the data included is from the most recent month and not outdated or incomplete figures. Staying current is essential for stakeholders to make informed decisions based on the latest information.
  5. Completeness: Comprehensive reports provide a thorough analysis of the presented data and information without omitting important details. For example, in a risk assessment report, include all identified risks, their potential impact on the project, and proposed mitigation strategies. Leaving out critical information could lead to uninformed decision-making and negatively impact project’s outcome.
  6. Consistency: Maintaining a consistent format and style in reports is essential for presenting information in a logical and organized manner. Consistency includes using the same headings, fonts, and colour schemes throughout the document. In addition, reports should have a clear structure, with sections divided into logical categories, such as background, objectives, methods, findings, and conclusions. This consistency enables readers to follow the report more easily and quickly locate specific information they seek.

 

Advertisement
[widget id=”custom_html-68″]

 

In addition to the above guidelines, it is essential to consider the training and education of both report writers and the intended audience. Providing education on avoiding jargon and understanding the needs of different audiences can significantly improve report quality. Additionally, fostering collaboration between SMEs and report writers can facilitate the process of simplifying jargon and creating more accessible reports.

When writing reports, it is important to tailor the level of jargon or technical language to the audience’s expertise. For instance, when writing for experts in a particular field, some degree of technical language might be appropriate. However, for a more general audience, strive to use more accessible language.

 

To further streamline the report writing process, consider using tools and resources such as readability checkers, jargon busters, and style guides to ensure clarity and simplicity. These tools can assist in identifying complex language and suggest alternatives that are easier to understand.

Measuring the effectiveness of simplified reports is crucial to understanding the impact on reader comprehension which may support decision-making. Some methods for assessing the success of simplified reports may include reader feedback surveys, comprehension tests, or monitoring the outcomes of decisions made based on the reports.

 

In conclusion, reports play a crucial role in project communication, documenting and conveying vital information to stakeholders such as team members, management, clients, and investors. Detailed analysis of data, trends, and other relevant information in reports helps project managers make informed decisions and improve project performance. By simplifying jargon, providing training, fostering collaboration, and using available tools, project managers can create more effective reports that drive informed decision-making and overall project success.

 

 

PMTimes_Apr12_2023

Practical PM for Everyone

Project management is a process that, when done well, enables optimal performance. Why wouldn’t everyone want to know how to manage projects?

 

Everyone Has Projects

A project is an effort to create a result in a finite time. According to PMI, “a project is a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.”

Everyone is part of projects. Some projects are long, large, and complex, like a lunar expedition or the implementation of a new system in an organization. Others are moderate and more personal – planning a party, buying a car, moving, painting your house. Others are quite simple, for example getting up and out of the house, packing for a vacation, grocery shopping, doing the dishes, cooking a meal. Even the individual activities of regular operations like answering emails or working to close a sale fit the definition of projects. we can consider them as mini-projects.

 

Therefore, everyone would do well to know the basic principles of project management and adapt them to the size and complexity of the projects at hand.

Professional PMs would add value by promoting wide-spread appreciation and knowledge of project management for all.

 

Agile Adaptability

Applying a complex project management process with forms, protocols, and reports to manage your at home cooking dinner project or a small project that is repeated many times is not skillful.

You might like to be formal and explicit because it makes you feel good but if there are others involved you might drive them crazy and waste lots of time and effort.

 

At the same time, doing any project without a plan, without writing things down (for example a shopping list), with ambiguous or inadequate communication, and without looking back to learn from the experience is equally unskillful. It is likely to lead to extra trips to the store to get missing ingredients, too much or too little food, misunderstandings of who will do what, and when.

Planning, performing, monitoring, controlling, and closing happen in every project, the way we do them varies widely depending on the situation. It was the intention of the earlier founders of the agile approach to point this out and promote the idea that the project team does best to adapt practices to the needs of their project, stakeholders, and setting, while being aware of the need for a degree of structure and discipline.

 

Advertisement
[widget id=”custom_html-68″]

 

The Agile Manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions     over     processes and tools

Working software                     over     comprehensive documentation

Customer collaboration            over     contract negotiation

Responding to change              over     following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

http://agilemanifesto.org

 

Communication and Collaboration

To enable an adaptive and agile approach make sure that all stakeholders have a sense of  the basic principles of project management.

The basics are what everyone should know about managing a project, even if they are not managing one. Knowing the process and principles stakeholders can assess how well the project is being managed. They will be able to connect a sense of the project’s health  accomplishment and progress.

 

The basics are:

  1. Plan, to create a clear sense of what is to be accomplished, how, where, by when, by whom, and for how much it will cost. Remember that plans are always subject to change. Planning is not over until the project is over.
  2. Let go into execution, the performance. It’s like dance or a play. You learn the steps and your role and surrender into performing them.
  3. Mindfully monitor and control to assess progress against the plan and to adjust. Make it part of the performance so it doesn’t get in the way.
  4. Close. Take a step back to assess performance. Tie up loose ends. Learn from the experience. Turn over the results.

So simple, if there is understanding, adaptability, effective communication and collaboration.

Without these the project management process becomes a burden. With them the probability of project success goes way up.

 

What gets in the Way?

You’d think that everyone would be eager to apply the basics and to understand, adapt, communicate, and collaborate. But it is not the case.  The principle things that get in the way are:

  • Lack of process thinking – Thinking all that is needed is to put heads down and do the work instead of recognizing that objectives are met by skillfully applying effort to perform a set of definable steps or tasks.
  • Too much process thinking – over formalizing project management, creating unnecessary bureaucracy and overhead.
  • Not recognizing the value – thinking that the effort to manage the project is not worthwhile.
  • Thinking that it is too hard to engage others in the work required – believing that changing stakeholder mindsets about project management is impossible.
  • Personality traits – for example, closed-mindedness, impatience, fear of being criticized and controlled, and over confidence block attempts to implement some degree of planning and control.

 

What to Do About It

Removing the obstacles to implementing the right kind of project management (PM) requires a learning process in which PM champions convince stakeholders that PM is a practical process that adds value by upgrading performance and promoting project success.

Breaking through resistance to PM requires mindset change and changing people’s minds is no easy task.

 

It is not just about getting people to take a PM course, though an appropriate one, with a skilled facilitator, is a good place to start. It is committing to a dialog that addresses resistance to applying PM principles coupled with a commitment to the agility to adapt the principles to fit the projects being performed and the people who manage and perform them.

It takes time and patience with an understanding that much of the resistance is reasonable given experience with dysfunctional PM and rigid project management professionals who don’t adapt the process to the situation at hand.

PMTimes_Apr05_2023

Best of PMTimes: Closing a Project: What, When and How

Projects, by nature, are to be closed. I am sure you know this. The two authorities made this obvious in their definitions of what project is.

 

Take a moment to review the definitions from PMI and AXELOS.

A project is a TEMPORARY endeavor undertaken to create a unique product, service or result. (PMBoK Guide 6th Edition)

The above is the definition of a project by PMI (Project Management Institute), an organization founded in 1969, with headquarters in the USA and who has been providing guides, standards, and certifications, amongst other things, on project management since its inception. The key word is that definition is TEMPORARY, which literally means must have a start and end time.

Let’s move over a minute and take a look at the definition of a project from another body.

A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case (Managing Successful Projects with PRINCE2, AXELOS)

One thing is common to the two definitions. Did you see it? Yes. It’s the word TEMPORARY. A project is temporary and must be closed. Don’t confuse the term TEMPORARY with SHORT. I have got few of this concern from some of the students I train. A project can be for between 1 month and 36 months. It just means it must start and end at a particular date

Now, let me take you through the WHAT, WHEN AND HOW of closing a Project.

Note: I will not discuss whether the project is successful or failed.

 

WHAT is Closing A Project?

It’s has been established that every project has a start date and an end date. So, the process of completing the work on the project to an end is exactly what closing a project is. Nothing more, nothing less. If you are not closing an exercise or ending an exercise, then you need to know that the exercise isn’t a project.

It could be an operation. One of the differences between a project and an operation is that while projects are temporary, operations are ongoing and continuous. No matter how long the duration of a project is, it must end.

 

WHEN do you CLOSE a Project

Well, there are three circumstances under which a project can be closed. Yeah, THREE! One out of every ten readers of this article will find this surprising. Just give me a second and I will explain the three times.

 

1. When the project has delivered all the objectives and/or RESULT.

This is probably the most popular and most desirous time when a project should be closed. At the beginning of the project, a set of objectives, deliverables, and results were set. The PM and the whole organization rolled up their sleeves and started working towards building and delivering the objectives and deliverables for the project. Once the objective is met and the deliverables completed and accepted by the Project Sponsor/owner, it is time to close the project. Reason? The PM and the team have completed all they committed to, and there isn’t anything left to do on the project. What if there is a modification or an addition to the deliverables of the project. Well, that’s called scope creep, if there is no adjustment to other components that may be affected, and once the addition didn’t go through change control for approval, and no re-baseline, then it has to be initiated as a new project, after closing the current project.

For PRINCE2, Once the project has delivered what was specified in the business case of the project mandate, while for PMI, once it has developed the content of the approved scope.

 

2. When the objectives of the project can’t be met again

This is often called TERMINATION. Hopefully, it can be done early.

This is usually not a very pleasant one, but it’s usually a reality. It could be as a result of the complexity of the project or a combination of many other things. I recall working on a project with some client in the financial services industry a few years back. The business case and feasibility were highly optimistic and the organization decided to invest in the project hoping for the objective to be realized. However, after series of attempts, efforts, and re-baselining by the project team and the stakeholder, it became clear to even the blind stranger that the approach and the technology chosen for the project couldn’t meet the objective, the organization had to terminate the project for that same reason.

At times it could be that the organization had spent so much money on the project, yet they haven’t realized any benefit and at every point in time, there was no sign that the project would still deliver the objective.
Please note that in most cases, the project manager and the team are not responsible for this, and often should not be blamed.

 

Advertisement
[widget id=”custom_html-68″]

3. When the objective of the project is no longer needed

This is often called early termination.

We live in a dynamic and constantly changing environment, and there are many actors and factors driving the market and corporate space. Most of these factors could be a technological change, a governmental policy, a change in strategy and direction for the organization etc. PRINCE2 advises that at every point on the project, the project organization should continually check for business justification, to ensure the business case is still valid. If at any point the organization realizes that the business case has become invalid, the only thing left is to close the project. A typical example was a project I was working on for a client to penetrate a new market and release a product that would solve a particular challenge. We were about 45% into the project when the government introduced an initiative that would address a similar challenge at no cost. It became obvious that the product would not make many sales, hence the objective and business case became invalid. We had to terminate the project immediately. This is better than going head to complete the project. Organizations don’t just initiate or complete a project for the mere sake of completing a project, the product of the project must be valid all through and the end product must be desired and desirable at all time.

Another example was a consulting project I was working on with a startup to rebrand the company. Midway into the project, there was a merger and acquisition with another company it became instantly known that there was no need to rebrand the company anymore. Again, this could be at no fault of the project team.

In the next section, I would highlight how to close a project, irrespective of when it is closed.

 

HOW to close a Project

No matter when. You need to close the project. About three years ago, I worked on a research project with about twelve other professionals to review project management processes and health check of organizations within three continents, and we found out that a lot of organizations don’t close projects well, and this is quite worrisome. As they were completing one project, the team was being drafted to other projects or assignment without proper closure process. Hence the reason I decided to write this article.

This process will be broken that into two different sections. The first section will highlight steps to closing a project whose objectives have been met, while the second would highlight the steps to close a project whose objective is either not needed again, or can’t be met.

How to close a project whose objective has been met.

  1. Confirm that all the deliverables have been completed and accepted by the appropriate approving authority. Here you will need to reference your plan, specifically your approved scope and acceptance criteria
  2. Obtain formal acceptance and approval (this could be by way of formal SIGN-OFF or whatever method has been agreed upon).
  3. Close any procurement component of the project.
  4. Gather the team and update lessons learned on the project.
  5. Release all resources and provide feedback as required.
  6. Complete end of project report and archive project information.
  7. Celebrate. And I mean it.

 

How to close a project whose objective can’t be met or whose objective is not needed again

  1. Validate the reason for the early termination.
  2. Determine all the deliverables that have been created so far, and ensure they are accepted.
  3. Obtain formal closure notification from the Sponsor.
  4. Close any procurement engagement.
  5. Update lessons learned with the team.
  6. Release resources and complete end of project report, capturing the stage the project was at when it was closed, the reason it was closed and the lessons learned and archive project information.
  7. Celebrate (if you have the courage to).
PMTimes_Mar7_2023

Projects are Fragile… Yet Their Failure Is Not Always Indisputable

The flight from New York to London was without incident. The pilot avoided turbulence by requesting timely altitude changes, the flight attendants were attentive, and food and drinks were surprisingly pleasant. The landing, however, was a little rough and those last few seconds surely influenced some passengers’ opinion of this 7 ½ – hour flight. For some, it turned the entire flight into a bad experience or a “failure”… even though – and unbeknownst to the passengers – a rough landing was required for safety purposes given the strong crosswind upon arrival (the landing gear must make contact with the runway as soon as possible). For others, the flight was satisfactory after all.

There are many variables at play that will influence the outcome of a flight and stakeholders (here the passengers) will have their views on the quality of that outcome. The same can be said about projects, what drives them and their final output. What appears to be a failed or semi-failed project might actually contain some silver lining elements.

 

Projects are fragile

As shown in Table 1, many project risk variables (we count 23 of them) can impact the outcome of a project.

Those can be classified in 5 broad categories:

  1. People
  2. Tools
  3. Communication
  4. Planning
  5. Strategy

Since projects are driven by people, it is not surprising then that the People category is the largest with 9 out of 23 potential root causes of project failure with some occurring at the start of a project but most of them taking place mid-course of a project life cycle which makes it harder to mitigate them in a timely fashion.

A large number of mitigating factors will require pausing the project, otherwise this would be equated to the overused expression of “attempting to change a tire on a moving car’. Many of the proposed mitigants require the intervention of a third party (e.g. stakeholders, steering committee or management). This adds yet another set of challenges to the needed intervention.

 

Advertisement
[widget id=”custom_html-68″]

 

Another layer of complexity is introduced whenever project risk drivers are correlated or become part of a domino effect. Did the lack of resources cause the project to be delayed and then the cost overrun? Did the lack of sponsorship lead to the project manager becoming disengaged and project risks not flagged in a timely manner? Or did those variables manifest themselves independently?

In most cases these project risk elements will be correlated that is why it becomes critical to identify them as soon as possible in order to make the appropriate course correction to avoid a project failure.

Table 1 presents a list of project failure causes – from start to end of project – and proposes ways to mitigate them. The purpose of Table 1 is not to simply present a comprehensive list of mitigants (as variations of such mitigants can be implemented as well) but rather to suggest that what is critical is to identify the project risk variable and begin the process of curing it by a variety of approaches.

 

Table 1 – Project Failure Drivers

 

Project failure is not always what it appears to be

In light of such a long list of potential project failure points, it is natural to then take a closer look at project failure itself, or more precisely the various types of project failure that might ensue. These can be broadly classified by the nature of the impact to the project delivery, which can have objective characteristics (e.g. defective delivery or cost overrun) or more subjective ones (e.g. poorly communicated outcome even for a successful project).

As shown in Table 2, many apparent project failures can have their silver lining, especially when it comes to impact on ROI (Return on Investment). Indeed, what sometimes appears to be a categorical project failure, can actually hide some degree of silver lining.

Table 2 – Project Failure Types

Finally, it is worth noting, as depicted in Table 2, that even though a lessons learned exercise is a must at the conclusion of every project – especially those deemed to have “objectively” failed – the depth and intensity of such an exercise may vary by failure type as one considers other priorities calling upon an organization’s resources.

PMTimes_Feb28_2023

Collaborative Relationships Between Project and Functional Managers

This article addresses the project manager/functional manager relationship with an emphasis on collaboration, reporting, expectations, and empathy.

 

One of the nice things about PM is that the principles don’t change much over the years. One of the disheartening things is that the problems also don’t seem to change. Collaboration remains a key to the wellbeing of organizations, particularly, the collaboration between project managers (PMs) and functional managers (FMs). It is still a challenge that hinges on clarity, communication, understanding, and empathy.

 

Over the years there has been continued interest in a paper I wrote 25 years ago, The Project Manager/Functional Manager Partnership[1]. The key point then as now is that there is a need for clarity regarding roles and responsibilities, priorities, and communication protocols regarding commitments and status.  Clarity leads to understanding, hopefully, resulting in empathy – a sense of feeling for others.

 

Roles and Responsibilities

The role of the project manager focuses on the accomplishment of project objectives – getting the work done on time, within budget to deliver a quality outcome.

The role of the functional manager, a manager of a department usually associated with a specific discipline,  is to ensure that properly trained and well motivated resources (people) are available for project work. Some FMs lead departments that perform the work as a service, while others provide resources to be directly managed by project managers.

For example, the manager of a project management office is responsible for making sure that project managers are available for assignment to projects. Those PMs report directly to a program manager or steering committee with regard to project related activities.

 

The manager of business analysts provides her department’s people for work on projects and programs. The BAs typically report to the project manager. A Quality Assurance manager provides testing services as well as quality management standards and procedures, and oversite in the form of audits. Testers typically report directly to the FM and not the PM. Other functional managers provide engineers, procurement experts, attorneys, and more.

The manager of a software development department may be responsible for providing programmers to work on projects and ongoing system maintenance activities. Or they may be responsible for managing the programmers for the delivery of software for projects.

 

Reporting To

Regardless of whether the task is to provide people or services, functional managers “report to” project managers in the same way that a contractor reports to a client.

The idea of what “reporting to” means is a point of conflict between FMs and PMs. Commonly the term means that there is a hierarchy in which the person reporting to the other is under the authority of the other.

 

In project work, the FM does not report to the PM in that way. The PM does not have the authority to tell the FM what to do and how to do it. But the FM does have the responsibility to tell the PM what is going on, to provide information regarding plans, estimates, projections, status, and changes to resource availability.

Part of the needed clarity is about how and when this reporting will be done. Perhaps the most critical part of this reporting process is notification of changes to commitments.

 

Advertisement
[widget id=”custom_html-68″]

 

In healthy organizations FMs take part in project planning. They provide estimates and resource availability information. Where there is a well-functioning project portfolio management process, there is clarity about which projects are to be initiated when. This clarity comes from the knowledge of functional resource availability as well as the priority of each project.

So the FM not only reports to the PMs that he/she/they  serves but also to the portfolio manager. Whenever there is a change to resource availability it will impact project performance.

 

PM as Client

I find the analogy between FM and contractor to be helpful. A contractor knows that satisfying the client is the most important part of the job. If the client is not satisfied the contractor will suffer. Rational and empathetic clients will understand the contractor’s situation, protect themselves by being realistic in their expectations, and creating agreements that include provisions for both penalties and flexibility.

The FMs that treat the PMs their departments serve as clients deserving quality service will add greater value to their organizations and will better serve their own staff.

 

The FM’s Situation

The FM and the savvy PM know that there are multiple “clients” vying for the same resources. The FM needs to satisfy them all. Just like some clients, some PMs try to ignore this reality, making themselves believe that they are the only one.

Just like some contracting firms, some FMs overpromise, often caving into unrealistic demands and putting themselves and their resources under unnecessary pressure.

This leads to unreasonable irrational expectations. And irrational expectations lead to conflict, overwork, stress, burnout and missed deadlines.

 

That is where understanding and empathy comes into play. Effective collaboration is based on the understanding of the other’s situation leading to the ability to maintain rational expectations. This doesn’t mean to be “soft” and allow oneself to be taken advantage of. It means being reasonable and rational.

The FM needs to understand the PMs situation. If the project is behind schedule because functional resources or services are not delivered as expected, the PM will be accountable.

The PM needs to understand the FMs situation. The FM is not in control if resources are out sick or leave, or if project priorities change causing resource shifts. The best the FM can do is to report the situation as it is to the PM and portfolio manager, and be open to having project variances clearly pinned to functional performance variances.

 

With reasonable and rational expectations set at planning time and made part of the overall organization’s project management and portfolio management process, there will be less conflict, less unnecessary strain on functional resources, and a greater probability of project success.

If there is chronic conflict between PMs and FMs an intervention that seeks the causes and works to resolve them.

 

[1] Pitagorsky, G. (1998). The project manager/functional manager partnership. Project Management Journal, 29(4), 7–16 (https://www.pmi.org/learning/library/collaborative-relationship-roles-well-being-organization-2062)