Skip to main content

Tag: Business Analysis

Project Managers & Business Analysts – Why Can’t We All Just Get Along?

Written by Kiron Bondale on . Posted in Articles. 9 Comments on Project Managers & Business Analysts – Why Can’t We All Just Get Along?

You might disagree with me, but there is a greater co-dependency between the roles of a project manager and business analyst than with almost any other pair of project roles.

No doubt, a project sponsor is crucial to a project’s success and it is critical that a project manager establishes a positive, mutually beneficial working relationship with their sponsor, but once the project gets underway, most project managers will find themselves spending much more time with the business analyst.

Requirements are one of the most frequently cited sources of project issues and an effective requirements management process can go a long way towards improving project predictability. Given this, one would expect that these two roles would naturally work very well together, or at the very least, would go out of their way to ensure that they weren’t impacting each other.

Unfortunately, in many of the organizations I’ve worked with, this isn’t the case, and while it might be easy to chalk up a few incidents to individuals, the number of times I’ve heard complaints between the two roles indicates there’s something deeper at play.

From the business analysts, common complaints about project managers include:

  • Appear to be focused solely on cost or schedule constraints without also embracing the criticality of having good quality requirements
  • Demonstrate an unwillingness or inability to provide assistance in ensuring that stakeholders are attending and contributing to requirements gathering or review sessions
  • Don’t bother to read or understand high-level project requirements documents
  • Support or initiate scope change decisions without proactively engaging the business analyst

On the other side, I’ve frequently met project managers who complain about business analysts who:

  • Appear to have no sense of time or cost constraints when producing their deliverables or appear unable or unwilling to provide effort or duration estimates for their work
  • Produce requirements documents which are unusable by other project team members or which don’t address the customer’s stated and unstated needs
  • Appear to forget that the second word in their job title actually implies the task of analyzing, distilling and refining requirements as opposed to just parroting what’s been received from stakeholders
  • Become unavailable for the remainder of the project’s lifetime as soon as their requirements documents have been signed off

While individual projects might suffer as a result of such challenges, the greater long term impact is the erosion of the mandatory trust and mutual respect which needs to exist between these roles – this will result in chronic challenges to projects.
While these symptoms appear quite varied, they usually relate back to one of the following two root causes:

  • A lack of clarity regarding the responsibilities, drivers and expectations of each role, based on the context of a given project
  • A lack of alignment in the performance objectives or metrics for each role, based on the context of a given project

One might assume that through osmosis if not through formal training each would be quite aware of the other’s role. This is absolutely the case when one is speaking theoretically about the functions which each performs. I’ve rarely heard complaints when project managers are being educated about the roles, standard practices and responsibilities of business analysts or vice versa. Trouble often begins when one tries to apply the theory to a given project and this is why I’ve added specificity in the ending clause of both of these root causes.

It’s common practice for project managers to have a preliminary expectations “get and set” meeting with their sponsors – this is often done as a particular executive might not have played that project role recently, or may not have ever worked with a particular project manager before. There’s really no good reason why a project manager shouldn’t extend the same courtesy to a role as critical to project success as the business analyst’s.

This meeting provides both individuals with the opportunity to walk each other through the practices they intend to apply based on the needs of the project and to discuss expectations each has for the other’s role. By covering “rules of engagement” at the outset, a number of future disconnects could be identified and resolved before they begin to impact project performance or the working relationship between the two roles.

Joint conferences have been held for project management and business analysis for many years, and PMI has recently announced a new certification in business analysis. Both of these are evidence of how inseparable the roles are. By taking the time upfront to understand how each role will work on a given project, one can almost hear the Turtles: “Imagine how the world could be, so very fine, So happy together”

Don’t forget to leave your comments below.

It all Happens from the “Get Go” 7 planning steps to achieve measurable results

Written by Richard Lannon on . Posted in Articles. 2 Comments on It all Happens from the “Get Go” 7 planning steps to achieve measurable results

Business leaders need to ensure that planning and implementation is focused. A well thought-out planning and implementation approach considers linking strategy, tactics and operational needs. It includes considerations for key business impact zones (productivity, tools, people and culture) and the outcomes required for solutions to business problems.

Consider the business objectives, the process and the work approach that must be used to successfully achieve results in an organization. Results should be resource-driven beginning with shared thinking and consideration of the challenges that need to be addressed. Call them points of pain. All businesses have them and every business leader knows it.

A checklist would be handy at this point. Consider common business challenges such as issues with focus and direction, trust, communications and collaboration, productivity, effectiveness and efficiency, process and work procedures, outdated equipment and tools, people experience, skills, beliefs, values or even blame-storming. No matter the issue, they all add up to one thing – a negative impact, something a business leader seeks to avoid.

Here are 7 steps to consider when planning for measurable results:

Step 1. Understand your business priorities

What five things are on the strategic agenda of the organization? Why are they so important to the business? In what way can your team make those items happen? If you can answer these questions you are on the path to good business leadership thinking.

Step 2. Identify the challenges

What are the points of pain? What are the key challenges? How are these challenges impacting the business? Can we qualify and quantify the problem? Have we considered the impact to productivity, our tools, people and culture? What are the overall impacts and ripple effects to the organization? Write a clear and concise business problem statement that everyone understands. Share that statement and engage in shared thinking and creative solutions with your people.

Step 3. Determine key solutions

Throughout the process, encourage teams to assist you in solving the business problems. Be careful here, as coming up with ideas on how to solve business problems does not mean implementing solutions. Provide support and insight to people whose natural approach is to roll up their sleeves and jump right in. At this point, as a business leader, you should be seeking thinking and solutions. Only after the ideas have been put forth do you seek to prove their viability.

Step 4. Choose a solution that makes sense

This is where viability comes in. It really comes down to what, why, who, how, when, where, how much and what’s in it for the organization, the benefit, risk and return factor; all the things we learned in grade school and on the playground only with more risk. The best thing is to review situations and possible impacts. Pick three solutions: the do nothing solution, the do something solution or the do something else solution. Think through the issues and make a decision.

Step 5. Implement the solution

It’s not always easy, but it must be done. As the business leader, make sure you have your team together. Establish your approach to deal with people and team dynamics across the organization. Change means push back so be prepared. Be honest about your resource abilities. Invest in their success through investing in your own development. Use a good business coach to avoid future issues. Make it part of the process so your people will embrace it. This is a preemptive approach for solution implementation. Remember, as the leader you do not need to be the sage on stage but be the guide on the side.

Step 6. Measure the results

Ensure that you have put the right items in place to measure the results. This could be at many levels. Answer the simple question: does it work? The answer needs to be a yes or no, not maybe or sort of, eh! Did you get what you expected? How long did it take? Is it over or under budget? Will you see the expected return on investment? If so, over how many years? Do we have the right people? Have you considered the impact zones and the impact? Does the solution (process, tools, people, etc) align with what is important to the business? The list of questions here is long and depends on what was set as the measurement needs earlier in the planning process.

Step 7. Capture lessons learned

This is an area that business leaders rarely engage in. Yet, it is extremely valuable at all levels in the business. A feedback loop should always exist and the business leader should explore what was learned internally and externally. This is your intellectual property that can be used for future planning and continuous improvement.

In the end, it comes down to following a planning and implementation approach that ties strategy and tactical solutions together. As the business leader your success depends on following a proven approach, engaging your people in the process and building key business skills. Planning for measurable results happens from the ‘get go’.

Don’t forget to leave your comments below.

Taking Care of Your Stakeholders

Written by George Pitagorsky on . Posted in Articles. 3 Comments on Taking Care of Your Stakeholders

When planning the requirements definition phase of a project it is necessary for PMs and BAs to consider the diversity of stakeholders and their need for clarity, care taking and accountability.

In a recent project to implement an enterprise wide software product and related procedural and organizational change, the PM initiated a process in which a large number of business operations stakeholders from different departments would take part in the analysis and discovery of requirements for changes to the package and to plan for the procedures they would follow to make the system effective in their business areas.

The process was referred to as gap-fit analysis.

Members of each of the business units were to be introduced to the system’s features that would impact their roles in a series of presentations and demos. Then the stakeholders would explore the system’s features in a sand box environment. They would use their experience and knowledge of their roles to decide on change requirements.

Senior management had agreed to the principle that there would be minimal change to the package. People would change their procedures to fit the package rather than change the package to enable retention of the status quo. 

The PM had a good conceptual plan and buy-in from senior and middle management. But, things started to go wrong when attendees (supervisors, clerical staff and lower level managers) began to complain about the fact that the schedule of presentations was dictated to them and they weren’t given sufficient time to clear their schedules. Some pressure from above got them into the presentations.

Then, having attended the presentations, which were informative and allowed time for discussions and questions, many attendees did not have a clear understanding of their next steps. They were unclear about what they were supposed to do and how they were supposed to do it, even though they were given a template to use to provide their input.

Some people left their presentations thinking that they had to completely change the way they had been working for decades simply because the new system and the IT department said so.

Others were anxious about using the sand box, an instance of the system that had been set up to enable them to “play” with the features that supported their roles. They were afraid to mess things up, even though the feedback template had a sentence on it that explicitly said that it was ok to just play without concern. Some never read the introduction to the template while others didn’t really let what they read relieve their anxiety.

Stakeholders did not know who they could call if they ran into trouble. They had not agreed to the arbitrary ten day time frame for doing their exploration and turning in their feedback. They were not given the “hand-holding” they needed.

Within a week of the onset of the presentations, senior business management was reporting the displeasure of their people and as a result, their own displeasure, to the PM and then, when the PM made excuses, to his director.

Several people did not really know what “Gap-fit” analysis meant.

Intervention Needed

An intervention was needed to turn things around and make the best of the situation.

What went wrong? What were the causes underlying the near failure of a logical and sound conceptual plan? What needed to be done to turn things around?

At the root of the problem were untested and incorrect assumptions and expectations:

  • The stakeholders’ needs and priorities were not fully defined and validated.
  • The need for speed was assumed.
  • The participants’ understanding of what was being asked of them, why it was being asked and how they should go about doing it was assumed but not validated with them.
  • Participants were expected to behave like assertive “professionals”.

Needs and priorities

The assumption that the needs and priorities of business stakeholders in a project are completely aligned with project priorities is more often incorrect than correct. Current operations always take precedence over any future oriented activity. Projects are always future oriented.

The desire to maintain the status quo is usually quite strong, even when the status quo is painful. People dislike uncertainty. There will be resistance.

Make sure participants in requirements gathering activities are given sufficient time to adjust their schedules and that they are convinced or at least open to the idea that the project will improve their lives and the health and well being of the business. Remember the participants are working full time on their current jobs and that the requirements definition work is extra.

Senior level mandates might get people into the room but it won’t necessarily make them receptive and cooperative.

The Need for Speed

Getting things done quickly in projects is a common excuse for sloppy planning and insensitive communications. Clearly, we want to get things done fast but not at the expense of quality. Over and over again we pay for moving too quickly by having to suffer the consequences of errors and omissions. Planning takes time. Assuming that people will know what to do and will do it takes no time, but is a formula for disaster.

In this case, a week or two spent on planning, documenting and vetting the schedule and process would have gone a long way to make for a more successful engagement. People would have better understood objectives, their roles and responsibilities, and the work they were to perform. Planning would probably have identified the need for support and it’s ramifications on cost and schedule.

Participants’ Understanding

Assuming that people know more than they do is all too common. Some may think “since I know something, everyone else does too.”

I once facilitated a knowledge exchange between IT specialists and the bankers they supported. At the break after the bankers made their presentation regarding their business one of the technology guys came over to me and said that he finally understood what it felt like to be bombarded with a bunch of acronyms that were totally incomprehensible to him.

When we ask people to do something, we need to make sure they know what we are talking about. We cannot rely on them to ask. People are often averse to asking questions because they feel it would make them look stupid. Yes, they need to get over that. But until they do, it is necessary to draw them out, explain things clearly and in a language they are likely to understand and get them to feed their understanding back to us. This takes time and effort, but less time and effort than doing it after the fact.

Assertive professionals

Expecting people to behave like assertive professionals is asking for trouble. First of all we barely know how such beings behave and even if we did there would be significant exceptions. Some people are naturally assertive while others have to work on it. The ones that have to work on assertiveness may not be aware of their need. They just do what comes naturally.

When faced with someone who doesn’t ask questions or make their needs known take the time and effort to draw them out. Intuit the questions they might have by reading body language and facial expressions. Ask questions like, “Some people may think that this is a dumb idea, why would they think that?” Use written responses and small group exec praises to get people who are reticent to express themselves in large groups to talk. Take the time to list probable questions and issues, both positive and negative, so you can raise them if no one else does.

Conclusion

To maximize the probability of the success of your requirements and design sessions take a service oriented attitude. You are there to serve the stakeholders not just to elicit and document their requirements. Being a good servant, you must anticipate their needs to give your stakeholders what they want and need before they ask for it. Intuit their needs and cater to them. Find subtle ways to transform resistance into cooperation by building trust and understanding stakeholders’ objectives and how they relate to project objectives.

Know the personalities of your stakeholders and the organization’s cultural norms. Adapt your approach so that you are giving them what they need in the way they need it. Test your assumptions, ask the stakeholders for their cooperation and follow up to find out if you have met their expectations.

Don’t forget to leave your comments below.

2014 Trends in Business Analysis and Project Management

Written by Elizabeth Larson on . Posted in Articles. 3 Comments on 2014 Trends in Business Analysis and Project Management

anderson FeatureArticle June19The close of one year tends to encourage us to reflect on what has occurred in business analysis and project management during the past year and think about future trends. To summarize the trends we saw in 2013, the need for project managers and business analysts to be trusted advisors and to influence stakeholders, whether on an Agile or more traditional project, has not disappeared. The same can be said for the demands to balance distributed teams’ needs for efficient and effective communication tools with organizations’ needs for consistency and security.

Below are the seven new trends we see in the Project Management and Business Analysis fields for 2014.

1. Continued frothing-at-the-mouth enthusiasm for anything “Agile.”

The “Agile” bandwagon hardly seems to be abating. Whether organizations have really adopted agile, or they have stuck their toe into the shallow end of the “Scrum-but” pool, appetites for big, waterfall-type projects have diminished all around. This concept is further reinforced in the PMBOK® Guide – 5th Edition, released a year ago, which identifies phase-to-phase relationship and project life cycle options that account for waterfall, agile, and everything in between. So even for the PMs who haven’t had exposure to a real agile environment, there is more comfort with the idea that many of the tools and techniques that have served them well in the past can be applied on all types of projects.

PMs will increasingly find it an easy sell to break projects into subprojects or smaller projects, whatever the project life cycle and approach. They know too well the cost of trying to define and control many large projects, and they know their stakeholders would rather see smaller deliverables sooner. It’s not agile, per se, but more, smaller projects will resonate strongly with stakeholders as they define what project success really means to them. 

The BA world is equally rabid about Agile, seeing the release in 2013 of the Agile Extension to the BABOK® Guide, ver. 2. Version 3.0 of the BABOK due out in 2014 will have an Agile Perspective, and we won’t be surprised if IIBA produces an “Agile Practitioner” sub-certification akin to the PMI-ACP certification from PMI.

2. Use cases will enjoy a resurgence, particularly on Agile projects.

Five years ago we wrote that we expected “Slightly less reliance on use cases and more movement towards user stories.” While many traditional projects have favored the use case technique these past five years, it is only recently that we have noticed an upsurge in the interest in and questions about use cases on Agile projects. And no wonder use cases are gaining traction. User stories, the most common format for writing Agile requirements, are usually created at a high-level of detail. In order for the delivery team to estimate the story during sprint planning and then build the story, it often has to be elaborated in more detail. This elaboration, called grooming the product backlog, provides enough detail about the story so the team can move forward. This is not an attempt to elicit all the requirements up front, but rather to minimize delays caused by poorly defined requirements.

Many Agile teams are beginning to realize that an effective tool for this grooming is the use case, which provides critical information, such as when the user story begins, when “done is done,” and what criteria have to be met to be accepted by the product owner. They are also seeing the importance of the use case narrative in describing decisions and paths that ultimately lead to the navigation, edits, and messages required for software user interfaces. Sure, teams can obtain this information by impromptu conversations with the product owner, but many Agile teams are starting to realize that the use case structure is ideal for getting the user story done more quickly and completely.

3. Business Analysis Focus on Design.

A trend that will continue into 2014 is the notion that business analysis work involves design. Much of the BA’s work includes fashioning solutions, so it is natural to think of this as design work. To some extent the discussion is semantic, in that business analysis has long included design work but using different terms, like “to-be requirements” and “logical design.”

In developing the 3rd edition of the BABOK® Guide, due to be released in 2014, The IIBA® has given “Design” an equal place at the business analysis table. It describes design as “a usable representation of a solution.” (See the article on the IIBA web site.) The technical community may take issue with business analysts doing “design” work, but one thing is clear: the BA community is laying claim to part of the design space and we’re not looking back. Look for an article from us on this topic soon.

4. Increased use of the “cloud” and the need for business analysis in choosing cloud solutions.

Cloud computing will continue to have an allure of the promise to reduce investment in infrastructure and operations. However, it’s been a tense year for those monitoring data security and privacy. Organizations may be increasingly “angsty” about organizational and project information being stored “out there,” but the reality of needing to make information easily available to distributed team members is going to continue to trump those concerns for the coming year as project managers and teams increase use of the cloud for storing and sharing project data.

However, we believe that because of security concerns, organizations’ willingness to analyze their security requirements and to align those requirements to the potential cloud solution’s security features will grow, translating into the need for more analysis of overall requirements prior to investing in new cloud solutions. The growth of cloud technology has created a plethora of options for organizations, so in order to maximize the investment and achieve the greatest value, organizations will use business analysis to evaluate prospective cloud solutions.

5. Less email, more connecting.

The lack of employee engagement is a hot topic these days, and the costs are as significant for the projects in those organizations as they are for the organizations at large. Furthermore, many, if not most, projects use geographically distributed team members, making the obstacles to engagement considerable. We expect that project managers and business analysts are going to spend more planned time in the coming year making an effort to connect with stakeholders, including team members. Fortunately, the number of synchronous communication tools (audio and video) continues to grow, which will increasingly render email a less desirable medium. For those without access to new tools, this may be the year that picking up the phone finds new favor among team members. Overall, those who can let go of the perceived need to document every conversation will reawaken to the intrinsic benefits of communicating with higher-context media other than email which uses only the asynchronous exchange of written words.

6. Business analysis will focus on communicating first and documenting second.

More organizations are realizing that the business analyst brings more value to the organization when they have exceptional skills to listen, observe, question, and probe for the real needs rather than simply producing documentation. As we noted last year, these skills must also include the ability to influence stakeholders in order to get the participation needed for understanding and acceptance of the recommended solution. Further, they must be able to communicate the results of the analysis back to the stakeholders in a way that promotes understanding and gains acceptances and buy-in. We predict that more organizations will jump on the need for “just enough” documentation, realizing that great communication targeted to the group or individual will go much farther than a 500-page requirements document.

7. Project managers will focus on requirements management.

In 2009 we predicted: “There will be a greater emphasis on requirements in Project Management.” This focus has mushroomed during these past five years, in part because PMI has shown a greater interest in requirements activities. The continued expansion of the Collect Requirements section in the PMBOK Guide®– 5th edition, as well as the creation of the PMI Requirements Community of Practice with its numerous webinars and articles on requirements management, has encouraged project managers to become immersed in requirements activities. We anticipate that we will see a new Requirements Management certification from PMI. After all, since PMI has completed a role delineation study, can a related exam be far behind?

Don`t forget to leave your comments below.

About the Authors

Andrea Brockmeier is the Director of Training Services at Watermark Learning. She has over 20 years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She is actively involved with the PMI® chapter in Minnesota where she has been a member of the certification team for many years. She has a master’s degree in cultural anthropology and is particularly interested in the dynamics of global, virtual teams.

Vicki James is the Director of Business Analysis for Watermark Learning. She is responsible for developing and maintaining Watermark Learning’s Business Analysis Training programs and serving as an instructor for both live in-person and virtual online classes.  Vicki has more than 15 years’ experience in the public and private sectors as a project manager, business analyst, author, and independent industry consultant and trainer.

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

Lessons Learned On Jury Duty Part 3 – Communicate the Plan and Provide Updates

Written by Elizabeth Larson on . Posted in Articles. 7 Comments on Lessons Learned On Jury Duty Part 3 – Communicate the Plan and Provide Updates

This is the third and final part of a three-part series on the lessons learned from jury duty. In Part 1 I explored the analogy of potential jurors waiting for assignments to stakeholders waiting for their end product. In Part 2 I examined the importance of communicating the complete scope, and in Part 3 I will talk about the importance of communicating the plan. Communicate the plan and provide updates. What could be more obvious—right? Then why is it so hard?

Develop a realistic plan. I think many of us have been trained to develop a plan suitable to the project, but often our project management training is forgotten in the midst of impossible deadlines and unrealistic stakeholder expectations. Many of us are either overly optimistic (“oh this shouldn’t take too long”) or pessimistic (“let’s give them the worst case so we’ll look good”), when what most stakeholders want is for us to communicate what we know when we know it. Often our overly optimistic estimates come from too little detail in our scope and tasks. Our pessimistic estimates often happen when we assume every risk is likely to occur, so we build mitigating tasks into the schedule.

In my jury duty experience the courts had an abundance of optimism. We were constantly being told to return promptly at a given time, only to wait and wait some more. Sometimes we waited for hours. The worst day was when we were told to arrive at the courtroom at 9:00 in the morning where we waited until 10:30 and then told to take a break. We heard nothing until 11:45 when the court clerk told us to take a lunch break and to be back promptly at 1:00 PM. We were all back at 1:00 PM, but heard nothing until 2:00 PM, at which time the clerk told us that we would start in a half hour—a total of five and a half hours of waiting. From my viewpoint, it wasn’t the waiting that bothered me, but the lack of communication.

I’ve been lucky in that I’ve always found stakeholders to be reasonable. It seems to me that when I am not focused on process or methodology, when I communicate status, even when the news is bad, and when I offer alternatives, that sponsors and other stakeholders while not overjoyed, are understanding and appreciative of the communication.

Our best guess is better than no guess at all. Many of us are reluctant to provide dates to our business stakeholders. And there are many reasons for our reluctance, among others:

  • We are afraid our estimates will become commitments once they’re in the hands of our sponsors.
  • We don’t have enough information to estimate with any degree of accuracy.
  • We don’t have enough time to estimate with any degree of accuracy.

Although we often feel like we’re “flying blind,” or rushing to provide estimates based on little information, the fact is that we have more information available to us than our stakeholders have. Sure, we need to influence them to accept that estimates will change as we get more information. But our stakeholders look to us to advise them of the status and forecast of our project activities.

In my jury example, I did not expect the court clerk to provide us with accurate estimates, having realized long ago that the two words—accurate and estimate– shouldn’t be uttered in the same breath. Ideally, however, she would have provided us a time to convene and what to expect. For example, she might have said that we would convene at 9:00 AM and why it was important that we be ready, even if other court proceedings might preempt us. She might have told us that if there were delays, she would come and provide updates to us as soon as she could. She might also have told us that sometimes she would be involved in other cases that would delay her being able to get back to us. The more we knew about her job and its complexities, the more understanding we, the potential jurors, would have been.

How often should we communicate changes? How often should we provide updates? Whenever there is a significant change to what we previously said. When we provide updates, we are not contradicting ourselves. Rather, we are communicating what we know when we know it. But I have heard project professionals say, “Oh, I don’t want to overwhelm my stakeholders. I don’t want to give them too much information.” And I have heard stakeholders complain that they’re getting too much information. How do we know how much is just the right amount? Ask them, but ask them when planning the project—set expectations upfront. Let’s plan collaboratively with them. During the planning process let’s ask them their preferences for being updated. When we have to give unwelcome updates but also give advice on how best to proceed, we provide a really valuable service.

Don’t forget to leave your comments below.