Tag: Risk

You Desire Success? Learn to Manage Daily to Your Top 3 Priorities

Written by Neal Whitten,PMP on June 6, 2017. Posted in Articles. 2 Comments on You Desire Success? Learn to Manage Daily to Your Top 3 Priorities

Managing daily to your top three priorities is crucial to your professional success. However, my experience is that most people in our craft do not manage their to-do list effectively.

This article will show you how. Doing so can boost your effectiveness, reputation, and career.

Instantly Identify Your Top Three Priorities

If I were to put you on the spot and ask you what are your top three priorities or problems at work right now—by the way, priorities and problems mean the same thing to me in this context—and you could not rattle them off within three snaps of the fingers then you are not a consistently effective leader. You might be thinking how dare I judge you by so little information; that if I would give you a few minutes, then you could come up with your top three priorities. But if you need time to identify them then I restate my assertion that you are not a consistently effective leader. Instead, you are managing your day by the plethora of interruptions that come your way; by the noise and the minutia that fall over you. You are allowing your day to be managed by others instead of you taking charge and managing to the most important priorities. You are too soft if you are not seizing control of your domain of responsibility and primarily managing to your top three priorities each day.

To-Do List

Let’s talk about how to do this. Most of you likely start your day with a to-do list of work items. That’s good. You should. However, what I do—and perhaps some of you do as well—is create the list the night before. Why? Well, I already have had a busy full day, and I know where I want to hit the road running when I come into work the next day. Therefore, the night before is a great time to populate the list. But another reason I’ll create the list the night before is to focus on the top three items on the list—the top three priorities. Let’s say the list has ten items: the top three and a bottom seven. Now, most of you will likely have lists with more than ten items, but I want to make the math simple for illustrative purposes. When I go to sleep at the end of the day, my mind—my subconscious—is working on solving or moving towards the solving of one or more of these top three problems. When I wake the next day, these problems are either solved or well on their way to being solved; I have a better grasp of what I need to do moving forward. All of us have this ability to help resolve problems when we sleep. Regardless, if you, instead, choose to take 5-10 minutes of quiet time at the start of your work day to create your to-do list, that’s fine.

Focus Predominately on Top Three Priorities

Now, let’s say that you are traveling home at the end of your work day and you recognize that you have not made headway on any of your top three priorities, but you have managed to cross off all of your bottom seven: Do not feel good about your accomplishments that day! Why? Because you worked on the wrong things. If, instead, when you head for home, and you have not worked on any of your bottom seven but managed to make significant headway on just one of your top three, you should feel very good about your accomplishments for that day. And here’s why: Your efficiency to work on your top three priorities defines your value—your contribution—to your organization, it defines your career; not the bottom seven.

30 Minutes or More Available, Work on Top Three

You might be thinking: Neal, it sounds like you don’t care if I work on my bottom seven. You’re right. I don’t care. In the big picture, they are insignificant. Look, if you have five minutes between meetings and you can eliminate one of your bottom seven, then go for it. But if you have 30 minutes or more between meetings, do not work on the bottom seven. 30 minutes is what I call significant time. You should be working on your top three priorities—they define your career.

Work Off Top Priorities within 2-3 Days

Your top three priorities on the list should be worked off the list typically within 2-3 days. If occasionally you have a top-three item on the list for up to a week that’s okay. What’s that? You say that the items that make up your top three typically would take weeks or months to solve and you would not know how to remove them from your list in just 2-3 days. Okay. I’ll show you how. Let’s say one of your top three priorities will take you six weeks to solve. Then put a six-week plan together. Identify the activities, their dependencies, their durations and who owns them. Then get agreement from all the people necessary to make the plan whole and fully committed and track the six-week plan like you do any other plan. Now replace that priority item from your to-do list with a new one.

What’s that? You say the six-week plan hasn’t completed and, therefore, the problem is still open? That you think the problem should remain on your list until it is solved? Look… You now have a good working plan to get it resolved. It’s being taken care of. You will track its implementation with the frequency you feel it justifies. Remove the item from your top-three list and replace it with another very important item that now needs timely attention.

Occasionally, Not Working Top Three Is Okay

What if you come to work occasionally and find you are not able to work on any of your top three priorities because of that day’s firefights and “please handles”? If this happens only occasionally, that’s okay. You work in a complex, dynamic environment. However, if it happens routinely, it’s not okay. If you cannot routinely work off your top three priorities, then you are the problem. If you are not working them off, no one else will—this is your domain of responsibility. You need help. You might be overloaded with work and need some relief; you might be poor at managing time, or it could be something else. Whatever. You need to seek and obtain the appropriate help.

Number One Reason Why Projects Fail

This is a good time to share with you what I believe may be a profound assertion. We have all seen lists touting the top 10 reasons why projects fail. The usual suspects include weak requirements, scope creep, lack of user involvement, unreliable estimates, incomplete staffing, poor communications, weak senior stakeholder support and others. However, from my experience, these lists miss the biggest reason—the number one reason—why projects fail: Because the project manager does not manage to his or her top three priorities on a daily basis. This is so important that I’m going to repeat it. The number one reason why projects fail is that the project manager does not manage to his or her top three priorities on a daily basis.

You might be wondering how come I’m so smart to get this while it appears that others haven’t? Well, I’m not that smart, but I am an old guy who has been around a long time. Longevity and persistence helps me pick up things. For example, over the years I have performed reviews on hundreds of projects in trouble. When I do, I always conclude with identifying the top three problems—the top three priorities—that the project manager needs to address immediately. When I examine these top three lists, the ah-ha moment presents itself. The top items on the lists almost always should have been resolved not days earlier but weeks or months earlier—sometimes years depending on the duration of the project. The lists show that the project managers were not effectively focusing on their top three priorities on a daily basis; otherwise, these problems would have been resolved or under control. So, again, the number one reason why projects fail is that the project manager does not manage to his or her top three priorities on a daily basis. This is a fundamental fact that knowing and adjusting your behavior to can significantly increase the success of your projects—and your career.

By the way, the article might have appeared to focus on Project Managers, not Business Analysts. Everything said here also applies to Business Analysts. The number one reason why Busines Analysts fail is that the Business Analyst does not manage to his or her top three priorities on a daily basis.

Now, become your imagined self!

Keeping Risks at Bay & the Astute Business Analyst

Written by J.A. Oliver, CBAP, CISSP, MBA on April 7, 2017. Posted in Articles.

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” – Mark Twain

Ah, yes, the wit and wisdom of Mark Twain; still rings true over a century later, in the business analyst’s world. More recently, former U.S. Secretary of Defense Donald Rumsfeld had famously talked about “known knowns,” “known unknowns,” and “unknown unknowns.” While Rumsfeld never talked specifically about “unknown knowns,” I believe that Mark Twain effectively filled that gap.

So, what can YOU do about all the risks lurking in the shadows, as the semi-omnipotent (like digging half a hole) business analyst?

I’m sure you all know about the “probability times impact” formula, which tends to be qualitative (i.e. scale of Low to High) in our world, then you propose mitigation responses; but as the BA the pressing question should be how you can share the daunting task of risk analysis and management with the project manager (PM). I see this as a joint effort in that the PM is chiefly entrusted with managing risks affecting time and cost, the BA and PM together manage risks relating to project scope, and the BA is primarily tasked with assessing risks relating to project quality. This stands to reason since the BA is concerned with product scope, whereas the PM is preoccupied with project scope.

So let’s get our hands dirty and dive into some salient aspects of risk. Are you ready?

1. Prioritizing Your Requirements Based on Risk Factors

What if the solution your organization wants to deploy is cutting-edge and entails a certain “leap of faith”? If something has no known precedent or proof of concept, there is an inherent risk to its quality on deployment – chalk that one up under “known unknowns.” (And try not to fret about the “unknown unknowns” while you’re at because let’s face it: you’ve got enough on your plate as it is.) As the BABOKv3 says in Section 5.3 on page 98, “If there is a risk that the solution is not technically feasible, the requirement that is most difficult to implement may be prioritized to the top of the list in order to minimize the resources effort before those resources learn that a proposed solution cannot be delivered.” Sage advice: if you can’t meet the quality threshold, you don’t want to encourage the PM to over-commit resources in vain.

2. The Personnel Dimension of Risk

This is where it gets tricky and sticky. Tricky because people have to be convinced; sticky because they don’t want to budge. It helps to know your organization’s appetite for risk, too.

In doing stakeholder analysis, you have to make sure that the right players – such as SMEs or regulatory stakeholders – can commit themselves to the team effort. If they are only sporadically available, or they are in “fire-fighting” mode all the time, then you might have to take a risk proceeding with certain assumptions until they can be validated. If they find fault with the conceptual solution and your initial requirements, then you’ll want to ensure their continued availability, as their approval is paramount. These are all factors that are known as engagement risk.

3. Assumptions, Constraints, and Dependencies

Typically, risks are documented along with assumptions, constraints, and dependencies for a good reason. It is because from these categories that risks are implied or inferred. As the BA, it may help to maintain a traceability matrix so you can convey potential flaws of assumptions, or whether dependencies have been fulfilled or are likely to be fulfilled – again, you’re more concerned with impacts on product quality, whereas project (and program) management is more concerned about duplication of effort (and costs). Once again, you need to consider the risk appetite of sponsors; that could very well be the impetus for a given constraint!

4. The Big Picture

Many organizations today use ERM or Enterprise Risk Management. These are high-level risk categories that need to be addressed in order to meet strategic imperatives. When you document high-level requirements (HLRs), consider how they may contribute to reducing these risk factors – thus resulting in residual risk. You could show a risk mitigation rating for each block of HLRs (i.e. a scale of Low-High); however, it may be difficult to do a risk rating attribute for each individual requirement. Your HLRs are expected to produce synergies to meet organizational objectives. Consider a formula that factors in priority values, too.

When thinking of the bigger picture, think about sources of risk; they could be more internally induced like culture or restructuring; or more commonly, they could be externally induced such as technology or market factors.

5. Value Realization and Risk

The moment of truth: you need to know if your undertaking has met certain quality thresholds. Has the solution realized its intended value? This is typically measured by metrics or KPIs (Key Performance Indicators). However, risks can ultimately derail your intended benefits; this, I believe, is where the framework of “(un)known (un)knowns” comes into play.

Achieving a reduced risk as an outcome, incidentally, is a benefit unto itself; albeit one that is not easily measured, as say compared to KPIs of increased efficiency, or reduced defects or downtime or complaints. (Section 7 of the BABOK speaks very well to this, by the way.) In this ever-expanding world of business intelligence (BI) and predictive analytics, one can run a “what-if” analysis to experiment with a range of outcomes, which could be based on risks manifesting.

6. Security Requirements

Lastly, some thoughts on security and risk; traditionally, security requirements have been in NFRs (non-functional requirements), or a logical roles matrix – since if anything threatens the CIA (confidentiality, integrity, availability) of your solution (which could be electronic or physical), then you effectively have a risk.

This is where an experienced technical SME, such as a senior designer, can be indispensable in sealing up the cracks in the armor as it were. You may need to introduce requirements that prevent certain malicious behaviors as per their advice.

Strategy Spotlight: 8 Things You Must do Better to Make Better Decisions

Written by Richard Lannon on December 20, 2016. Posted in Articles.

I have been thinking lately about what it takes to make decisions. Just recently I was presented with a situation where some major decisions will need to be made.

Ones that impact changes in business and careers focus and could mean going into a whole new direction. So you have to make the best decision with the information at hand for your organization. From that perspective I think there are eight things you must do to make better decisions.

1. Invest in decision making skills.

This is something that holds true today as it did ten years ago or more. I see this as a foundational skill that people need to learn, practice and apply. There are many approaches or methodologies that can be applied in the decision making process whether you are a traditional organization, project based, a committee environment or driven by the board of directors. Often the fundamentals of decision making are missing. Look at the environment and create an appropriate decision making structure.

2. Create time to think ahead.

Time, time and more time is something we don’t have. It has become a luxury that most people can’t afford. Yet making good decisions requires time to reflect and look at the road ahead. What if you are considering changing careers and decide to go in a whole new direction? This is a big decision. This applies to a business venture also. Change and transformation are difficult to do on a whim, often you are required to think and plan ahead. But don’t over think long term plans as things change around you quickly.

3. Know who you serve.

This is an important point to answer. I know a lot of business leaders and professionals who I am completely confident in their ability to get the job done, to move forward and make things happen. But, they lack an important insight and clarity of who they serve. Decision making is a whole lot easier if you know who you serve whether it is a specific target market, an organization or something else. I think it provides opportunities to make mindful decisions and improve innovation and creativity in solving problems due to clarity and focus. It does not matter if you upset the market because you know who you serve.

4. Question everything, especially the business.

I often get asked how I would approach a specific problem. I am in a meeting and someone sets up a scenario and wants to know my approach. Any good business analyst, trainer or consultant will know the basics; define the problem, evaluation solutions, implement the approved solution, and measure the results. Part of the process is to question the business model. Recently I had this happen in a meeting with an executive director. I was presented with a question and responded but within that response I placed questions to better understand the business model of this organization.

Turns out they are looking for a change and the business model is suspect. It is always good to question, even when answering.

5. We can all think in a straight line.

Straight line or linear thinking is the a, b, c, of decision making. With so many organizations talking about innovation, creativity and being intentional I wonder what’s the point. There are many theories about what approach you should take. I still think the best approach to decision making and initiative integration is a mix between predictive and adaptive planning. These two approaches provide the best of both worlds, and when blended, often provide an organization an approach that works beyond the mere linear.

6. Create a story around decisions.

Life is a story and you write it yourself. With every decision there is a story that comes from people discussions, thinking, making assumptions, determining impact and communicating the decision. Wouldn’t it be great if you could create a decision narrative that is beyond the old boring business report? People want to be part of the decision story that makes a difference thus bridging organization gaps. You should create decision making stories.

7. We are all moving at the speed of a click.

Over decades my career has been part of the professional consulting and service economy which has accelerated at lightning speed in recent years. When I look at the professions’ value stream I think we need to make better decisions around the downstream business environment. Clients no longer just order or buy stuff they engage now in a very different way where it becomes difficult to determine the ROI on business activities. Margins wither as the need to provide valuable free content increases making business decisions a challenge to make. No matter the business you are in, the accelerated service economy is impacting your business.

8. Find a tool, reduce your risk and get costs under control.

The strategic business analyst looks at the past, present and future of a strategic plan and approach and use financial analysis of NPV, IRR and ROI within your business case. But it is important to go further and look at risk with uncertainty analysis. This is something that I learned over time from various economic adjustments (ie: dot com bubble burst, corporate and accounting scandals, subprime mortgages issue, and resource industry collapse) I think uncertainty needs to be determined better. Business intelligence and uncertainty reducing tools can be used to assist in this analysis. My point, the business analyst can play an important part in helping organizations make decisions through embracing uncertainty analysis approaches and tools to help deal effectively with unpredictable times.

Final Thoughts

Big decisions are tough to make, especially when you have invested so much time and effort on your business or focus area. When you work in a space where you are building skills and helping businesses define their future, you start to realize that there are certain truths that exist. One truth, everybody wants to survive and be around a long time. The second truth, that there is always a purpose that needs to be achieved. Third truth, good decisions and core competencies take you a long way to creating a profitable future thus achieving the first two truths.

From the Archives: Diving Into Unofficial Roles & Responsibilities of the Business Analyst

Written by Angela Wick on August 18, 2016. Posted in Articles.

Why are we the psychologists and the babysitters?

Often on airplanes I get asked, “So, what do you do?”

I am sure if you travel you get this one as well! Do any of you answer with “I am a therapist?”

Well, I do, and it works really well! I am a therapist that helps business teams and technology teams work together and create meaningful products, services, and systems.

I help them agree on changes and create a shared understanding.
I create a process and platform to communicate.
I make them both feel like they are the ones who came up with the ideas.
I make conflict seem like a non-issue and create win/wins.
I present options and alternatives and work through, with the pros and cons.
And, they pay me an hourly rate to do this!

You rarely see “therapist” on a list of required BA skills, but a comparison of BA job descriptions across industries, across nations or even across a single organization, yields an amazing variety of responsibilities and required skill sets. Even the industry leading IIBA BABOK (embedded link: http://www.iiba.org/babok-guide.aspx) highlights more than 20 underlying competencies that support the professional practice of business analysis.

Related Article: Your Next Business Analyst Will be a Robot

Lengthy BA skill lists that include creative thinking, technical skills, adaptability, listening, solution knowledge, teaching, testing, leadership, facilitation, etc., confirm our reality that BAs are expected to be the Swiss Army Knife of the project, product, IT, or operations world. It’s no wonder that most BAs claim to “wear many different hats.”

Despite the wide variety of accepted roles and responsibilities, BAs are often asked to wear strange hats—to take on unofficial duties that don’t really fit the wide range of normal. I get asked in my classes on a regular basis: “Is it the BA’s role to ___________?” Students fill in the blank with common things like testing, coding, and project management, but hostage negotiator, spy and therapist have also landed at the end of their question!

Here are a few true stories I’ve collected over the years, with names changed to protect those who might be embarrassed by their big, floppy, gaudy, leopard-print hats:

Undercover Agent

BA Becky was a well-respected senior BA in her organization. The BACoE leader recognized her accomplishments by asking her to mentor a struggling team. The odd part of the assignment—BA Becky was asked to be an undercover mentor—she was not allowed to tell the team she was mentoring them.
BA Barry was on a project team that needed to create a pricing strategy for the organization’s products. The strategy included several assumptions about their competitor’s pricing. The team leader asked BA Barry to “secret shop” the competitor to validate the assumptions.

Ghost Writer

BA Beth asked her stakeholders from California, Texas and Arizona to travel to Minnesota for a full-day face-to-face requirements review meeting. The day before the big meeting, the project manager realized that BA Beth’s requirements were a huge mess. The requirements review would be a disaster. So, the PM asked BA Bart to stay late, re-do BA Beth’s requirements, and bring the new and improved requirements document into BA Beth’s meeting.

Translator

BA Brody was fluent in Spanish, so it makes sense that he was asked to review, translate, and validate a 6-months old, 300-page requirements document written in—Portuguese! The business sponsor asked, “Since you are fluent in Spanish it won’t be too hard to translate, right?”

Scapegoat/Peace Negotiator/Psychologist

A crafty project manager tossed BA Ben under the bus when she asked Ben to present a feasibility analysis to an erratic, f-bomb-wielding business owner. The business owner had great vision, but cost and feasibility did not meet his expectations, and the PM did not want to be in the line of fire.
BA Belinda got along well with everyone on her project team. So, naturally, the project manager asked BA Belinda to “figure out” a way to get a notoriously mean and stubborn database engineer to cooperate with the team.
Late one afternoon in mid-October, BA Betty found out she would be laid off at the end of the month. That same day, BA Bill was asked build a relationship with Betty to get the information he needed to take over Betty’s requirements work for a few projects. Obviously, laid-off BA Betty was NOT excited to do the knowledge transfer!

Babysitter

BA Brent was very smart but quite odd. His analysis work was solid, but his social skills were suspect. The team leader asked BA Betsy to help Brent stay focused, to monitor his interactions with the business SMEs and to step in when needed to ensure deadlines were met.

After Hours Snooper

BA Bill worked in a business unit where employees processed checks. Employees were required to secure the checks when they left the office each night. To validate compliance with check procedures, BA Bill was asked to stay late one night to search employee cubicles for unsecured checks.
Important documents were missing from several client files in BA Brenda’s organization. Brenda’s team leader asked her to return to the office after hours and search processing analysts’ desks for the missing documents.

Data Detective

A third-party software vendor refused to provide their data model to their customer. The customer needed the data model to develop requirements and meet the needs of their business. BA Barb, a member of the customer project team, was asked to reverse engineer the vendor data model.

What is it about the BA role that makes us prime targets for these odd assignments? I don’t see project managers or testers or developers wearing these odd hats.

The majority of these unofficial roles rely on our ability to build and maintain relationships with a wide variety of people. Maybe, these odd assignments are a compliment? Perhaps people skills are the primary strength of effective BAs, and these unofficial roles are just a side-effect of our success.

Have you ever taken on one of these odd roles or do you have another unofficial BA role to add to my list? Share your story in the comments below!

Note: This article was originally published on batimes.com on September 14, 2015

Well, I do, and it works really well! I am a therapist that helps business teams and technology teams work together and create meaningful products, services, and systems.

· I help them agree on changes and create a shared understanding.

· I create a process and platform to communicate.

· I make them both feel like they are the ones who came up with the ideas.

· I make conflict seem like a non-issue and create win/wins.

· I present options and alternatives and work through, with the pros and cons.

· And, they pay me an hourly rate to do this!

Here are a few true stories I’ve collected over the years, with names changed to protect those who might be embarrassed by their big, floppy, gaudy, leopard-print hats:

Undercover Agent

· BA Becky was a well-respected senior BA in her organization. The BACoE leader recognized her accomplishments by asking her to mentor a struggling team. The odd part of the assignment—BA Becky was asked to be an undercover mentor—she was not allowed to tell the team she was mentoring them.

· BA Barry was on a project team that needed to create a pricing strategy for the organization’s products. The strategy included several assumptions about their competitor’s pricing. The team leader asked BA Barry to “secret shop” the competitor to validate the assumptions.

Ghost Writer

· BA Beth asked her stakeholders from California, Texas and Arizona to travel to Minnesota for a full-day face-to-face requirements review meeting. The day before the big meeting, the project manager realized that BA Beth’s requirements were a huge mess. The requirements review would be a disaster. So, the PM asked BA Bart to stay late, re-do BA Beth’s requirements, and bring the new and improved requirements document into BA Beth’s meeting.

Translator

· BA Brody was fluent in Spanish, so it makes sense that he was asked to review, translate, and validate a 6-months old, 300-page requirements document written in—Portuguese! The business sponsor asked, “Since you are fluent in Spanish it won’t be too hard to translate, right?”

Scapegoat/Peace Negotiator/Psychologist

· A crafty project manager tossed BA Ben under the bus when she asked Ben to present a feasibility analysis to an erratic, f-bomb-wielding business owner. The business owner had great vision, but cost and feasibility did not meet his expectations, and the PM did not want to be in the line of fire.

· BA Belinda got along well with everyone on her project team. So, naturally, the project manager asked BA Belinda to “figure out” a way to get a notoriously mean and stubborn database engineer to cooperate with the team.

· Late one afternoon in mid-October, BA Betty found out she would be laid off at the end of the month. That same day, BA Bill was asked build a relationship with Betty to get the information he needed to take over Betty’s requirements work for a few projects. Obviously, laid-off BA Betty was NOT excited to do the knowledge transfer!

Babysitter

· BA Brent was very smart but quite odd. His analysis work was solid, but his social skills were suspect. The team leader asked BA Betsy to help Brent stay focused, to monitor his interactions with the business SMEs and to step in when needed to ensure deadlines were met.

After Hours Snooper

· BA Bill worked in a business unit where employees processed checks. Employees were required to secure the checks when they left the office each night. To validate compliance with check procedures, BA Bill was asked to stay late one night to search employee cubicles for unsecured checks.

· Important documents were missing from several client files in BA Brenda’s organization. Brenda’s team leader asked her to return to the office after hours and search processing analysts’ desks for the missing documents.

Data Detective

· A third-party software vendor refused to provide their data model to their customer. The customer needed the data model to develop requirements and meet the needs of their business. BA Barb, a member of the customer project team, was asked to reverse engineer the vendor data model.

What is it about the BA role that makes us prime targets for these odd assignments? I don’t see project managers or testers or developers wearing these odd hats.

Have you ever taken on one of these odd roles or do you have another unofficial BA role to add to my list? Share your story in the comments below!

5 Things Your Project Customer Assumes You Know

Written by Brad Egeland on February 15, 2016. Posted in Articles. 4 Comments on 5 Things Your Project Customer Assumes You Know

The Business Analyst and Project Manager should be focused on the success of the engagements they are leading. The Business Analyst is leading a team of skilled resources who should have one common goal in mind – to roll out a successful solution to the project client.

Do we know everything? No. Do we know everything about the project we are leading and about what we are supposed to be doing? We should! We aspire to, but there are likely a few things missing along the way. We learn as we go along. Do we know what our customer is always thinking? What they think about our performance or how we are managing them, the team and ourselves? No.

Well, I’m hopefully going to close that knowledge gap a little.

Here are my top five things that your project customer assumes, hopes or wishes you knew about them and the project you are leading for them.

You’re the expert, not them.

You are the skilled Business Analyst or consultant. You and the Project Manager are the individuals leading the team with the skill set needed to identify, design, and develop their solution. If they had that skill set or the time to do it, they wouldn’t need you.

{module ad 300×100 Large mobile}

Understand that you are the expert. The client knows that and wants you in that role. They may annoy you, demand things, they may even seem like they are getting in your way or trying to take over, but really, at the end of the day, they will be the most satisfied and confident if you are in control, take the lead, and direct them.

Money is very important to them.

We all must answer to someone higher up with respect to budget, profit margin, and overall financial health of the work we are performing. It works the same way for the project sponsor.

The project customer cares about the money they are spending on the project, and they want to feel comfortable that you are spending it wisely. Therefore, they expect this to be reflected in any weekly status reporting and dashboard view in terms of actions, work progress, and often budget analysis.

They have a day job.

They want you to know that while the project is very important to them and may be an important part of their career, they also have a day job. Rarely is the project you are working on their only responsibility. After all, they shouldn’t have to do too much on the project because you and your team are the real experts, not them, right?

They have other tasks to perform, bosses to report to, and even teams to lead. So they might not always be available with the information or decisions you need.

Keep them engaged, give them time, and be patient. And take charge and make good decisions in their absence.

They do not know how to test very well.

Your client may not like to say it, and they may not show it, but it is often the case that project customers do not know how to test very well. And they certainly won’t be experienced on this new solution you are planning to implement. Help them. Don’t do it for them – that would be a conflict of interest. But you can help them with test cases and test scenarios and hold their hand through the user acceptance testing (UAT) process.

You may find yourself and some individuals on your team spending more hours before and during UAT than you had in estimated in the budget, but it’s worth it, and you’ll know to include more hours in the schedule and estimate next time.

You are not their friend.

Keep it professional, no matter how friendly or easy the communication becomes. If you let it go too casual, you risk missing some information sharing along the way by assuming the other party may already know.

The customer may seem very comfortable with you, but you are still not their friend. They are paying for your services. Run professional meetings, continue professional conversation, and engage them like they are the project sponsor, not your friend from high school. And avoid the drinks at the bar with them after a big onsite meeting – it’s just not professional.

Summary / call for input

We do everything we can for our project customers. Lead their projects, manage the budget, engage them and try to keep them as focused and confident as possible throughout the project. But we can’t get inside their head, and they don’t tell us everything. If we could, though, these are things that I feel they would be thinking that we should know as far as what is driving their behavior and management of the process.

Remember, the Business Analysts, Project Managers and teams are the professionals hired to manage the projects. But in the end, it is the customer’s project, so keep them engaged and informed throughout. Have those periodic one-on-ones with the project sponsor to ensure that you know what they are expecting of you on each engagement and at every turn. Sometimes their expectations need to be reset, and that’s ok.

The key is never to stay out of touch with them for very long.

What about our readers? What do you think your project customers assume you know about them and the projects you plan and manage for them? What do you think they wish you realized as far as what’s important to them? What, from your experience in working with project customers and key stakeholders, would you add to this list or change about it? Please share and discuss.