Tag: Requirements

When to Document in Agile Projects

Written by Larry Blankenship on . Posted in Articles. 1 Comment

One of the planks of the Agile Manifesto states, “We value working software over comprehensive documentation.”

Unfortunately, people working on the project take this to mean that working software is sufficient and there is no need for any documentation. This could not be further from the truth. What do you need to document? In this article, I’m going to give you some suggestions for deciding what needs to be documented outside of the comments in the software (and yes, commenting your code is still useful as long as you focus on what and why, not how), and what got captured in in the ticketing or project management tool.

There are three places where you can create the most value when doing documentation outside the ticketing system:

  • Tracking Decision Making
  • Meta Data about the Project
  • Process Integration

Tracking Decision Making

Typically, tracking of decisions that the team made in each story happens in the Project Management System or in a system like JIRA or TFS. However, there are times where it will be useful to have a summary that captures the major decisions, who made them and why. This can come in handy during the maintenance process where knowing why the team made a specific design decision may be the difference between changing a variable and rewriting a whole section of code when a change is required.

It can also be helpful during reviews and project post mortems when it can be essential for capturing lessons learned during a particular sprint. A simple way to approach this is to use a list in Sharepoint or an Excel spreadsheet with the following headings:

  • Release
  • Sprint
  • Description of the issue
  • Summary of Discussion
  • Decision Made
  • Effect of Decision

Metadata About The Project

Often, much of the information about the application will be self-contained, which is perfectly good as long as you have the hood up and can get at the wires underneath with ease. There will be times however, that having the application be a black box is going to cause issues for people who work on the application later. Even though applications are supposed to be black boxes, it’s good to keep notes on where the keys are so if you need to unlock the box later, you can.

Information that can be helpful in this instance includes:

  • When the application went into production
  • Location of the source code
  • Location on the network where the production application is located
  • Database connections or at least which database contains the application data
  • Business Owner – Who has the authority to make decisions about the application?
  • External Web Services or FTP servers that are used and any credentials needed (We store credentials in a central password vault)
  • Any coding standards used (this can be very useful when the work is being done by contractors who may not be available for maintenance work).
  • Any off the shelf applications that may be part of the system. This can be especially important when the off the shelf application gets an upgrade or has the version in use deprecated.
Advertisement

Process Integration

I am a big fan of process documentation. As one mentor told me, “If it’s not documented, it’s not a process, it’s a regularly occurring event.” ISO-9000, one of the most popular quality standards devotes several clauses to documentation. Process documentation provides a record of the baseline of your process, which you can then use to monitor changes and how well those changes worked.

When dealing with a new system, I like to know how the user will do the process with that system, not just how the system works. When I’ve taught software classes in the past, I’ve focused on a task and how to use the tool to perform that task rather than just how to use the tool. For example, when I taught Powerpoint, I taught how to create effective presentations using Powerpoint, rather than just teaching Powerpoint.

I personally prefer to use flowcharts for process documentation, but depending on your industry and regulations, you may have to write something more formal. The most important things to document when writing process integration documentation are:

  • What job title does the process?
  • How many people do the process (useful later when prioritizing trouble tickets)?
  • Can the process still be done manually or via a work around if the application isn’t working?
  • What are the inputs and outputs for the process?
  • Are there feedback loops to let the person who created the input or output whether there was an issue?
  • What is the value created by the process and how does the software contribute (this is something that you probably did during the requirements phase, but it’s good to go back and review to make sure something didn’t change in the meantime.)?
  • Keeping some kind of history of changes and so forth can also be very helpful.

How Much is Too Much

One of the reasons that working software is valued more than comprehensive documentation is that comprehensive documentation is a huge consumer of project resources, both in creating the documentation, and in maintaining it. Massive quantities of documentation can result in binders full of information that no one will actually end up reading, or that will be out of date almost immediately. Keeping documentation at a useful level is very similar to writing user stories for a software project.

As a Developer

I need to be able to easily find metadata about an application

So that I can start working on maintenance tasks immediately when asked

As a Project Manager

I need to be able to see a history of decisions made about a project

So that I can improve the decision making process

As a User

I need instructions that show me how to do my job with the application

So that I can be productive immediately and reduce my learning curve

Albert Einstein addressed documentation and software design when he said “Everything should be made as simple as possible, but no simpler.” Understanding the value of what you document will help you do just that.

5 Reasons Why a Great Project is Like Good Chicago Style Pizza

Written by Brad Egeland on . Posted in Articles. 1 Comment

Comparing project management to a Chicago style pizza may be quite a stretch, but you need to first understand how much I like pizza.

When I’m in Chicago, I always need Chicago style pizza like Giordano’s, Pizzeria Uno or Lou Malnati’s. Once when I was in Boston for a week long training session with my manager who happened to like pizza as much as me -early in my professional career ended up eating at probably 5-6 different pizza places… In a week. So, when people say “I could eat that morning, noon and night”… With pizza I literally would be ok with that. When we first moved to Las Vegas I came first and stayed in the Luxor Hotel and Casino for a month and looked for a house for us while working in the IT department managing the corporate IT application development team, I ate at the food court every day in there. And there was a pizza place… So, I did literally have pizza very nearly every day for a month. I was ok with that.

Let’s take this very odd analogy a step further and consider these five ways or reasons why a great project is like a great Chicago style pizza… bear with me here… you may or may not enjoy this – who knows but please do let me know through feedback.

The crust is the foundation of a good project.

The crust sort of makes the pizza, right? Bad crust is hard to overcome. Everything else can be great, but on soggy crust it’s still just a bad, unsatisfying pizza. And sometimes crazy good crust can bring a pizza back from the dead if the other ingredients are so-so. You know what I’m talking about. For me, the crust is the leadership of the project. Yes, an easier project can have a “fake it till you make it” project manager who is still barely experienced at leading teams and projects. Everyone has to start somewhere. But not many organizations – unless they are so startup or so startup with their PM infrastructure – are going to put a brand new project manager in front of a $1 million project customer. You need experienced project managers in your infrastructure or project management office (PMO) to lead most of your projects – especially the more visible and high priority or complex projects. You can’t just phone in the leadership of these projects… They require the solid leadership and communication skills of the seasoned and proven successful leader of projects to keep those important customers satisfied and happy and coming back for more work and adding more revenue to the organization.

It’s all about the sauce.

For me, the sauce is a critical ingredient of the pizza. Bad sauce, bad pizza. In this scenario, the sauce is like the project communication. Communication is Job One for project leaders and poor communication can and will definitely bring down any size project. The project manager must be an effective and efficient communicator for the project and the team and the customer. That’s meetings, email, adhoc calls, regular weekly status meetings, team meetings. Any and all communications and follow up on key communications is very important so as to ensure that everyone that was part of that communication is on the same page afterwards. If a weekly status call with the team and customer happens, then follow up afterwards with notes asking them to respond with feedback or changes within 24 hours to ensure everyone understands and received the same information. One mis communication can lead to missed last assignments, tasks not being completed or even worked on when you thought you had everyone on the same page, but they weren’t. Never take understanding for granted.

Advertisement

What toppings do you like?

The toppings are big because each pizza has different toppings and add different flavor to the pizza. The toppings are the project team members because they vary with each project and with the skill needs for each project. Some projects actually need two business analysts – I’ve had several projects like that – so that’s like double pepperoni, right? Seriously though, some ingredients are just critical on nearly every project and I believe that – especially on tech related projects – cyber security is becoming one of those ingredients… At least as an input to risk planning and management. So that may be the cheese – hard to have a good Chicago style pizza without cheese! And yes, some teams always have the same types of skill sets because they are similar projects, but the great thing about projects is you can have a huge variety of skill set needs – you just need to understand the needs of the project and obtain the right resources and associated skill sets accordingly.

Perfection takes time.

The perfect pizza takes time to perfect and then it takes time to plan for and repeat that success. Likewise, with projects. Planning is a critical aspect of any good, successful project and lessons learned – just as you learn to make the perfect pizza – must be part of the process if you want to add to your skills and become better managers of the projects, customers, and teams you lead along the way.

Better than the imitators.

The best Chicago style pizza is going to be better than its imitators through hard work, great ingredients, a good team of workers, and a proven recipe of success. And there will be imitators just as there will always be competitors for the work you do or the software you make or the products you build or whatever you are doing for your project customers. You must work toward excellence and remain better than your imitators – your competition. They will always be trying to gain on you and take your customers away from you. Stick with your proven best practices, always be learning and improving and perfecting, and you’ll keep your customers and keep winning on your projects.

Summary / call for input

Building great pizza takes skill… And building the perfect project for your customer and their end users takes skill, planning, learning, time and the right teams. Very different yet very similar. But both take key ingredients to come out great at the end.

Readers – what’s your take – what would you add to this or do you even agree with my pizza obsessed comparison. I know it’s a stretch, but thanks for reading and let me know your thoughts on this.

Differentiating Differences that Make a Difference

Written by Robin Goldsmith on . Posted in Articles. 1 Comment

Perhaps you’ve noticed that a lot of people write, speak, train, and consult about Business Analysis (BA).

The number involved grows quickly when we also include those dealing with systems analysis (SA), requirements analysis (RA), requirements engineering (RE), requirements management (RM), and whatever related two-letter acronyms you no doubt could add.

For the most part, each of these probably represents different names for the same thing. Yet, presumably those claiming one term versus another think theirs is somehow different from the others—in some important way that truly makes a difference. Ironically, if indeed there are differences among these terms, they are hard to tell because there are no agreed-upon definitions that actually differentiate among them.

In fact, it gets worse. Thus, one partisan is convinced their term represents a particular characteristic; whereas someone else feels equally strongly that that characteristic represents their different term; and each is unaware of the other’s perception. Stepping back a bit should make evident how silly it all is; but of course, nobody sees folly in something dear to him/herself. It’s not limited to BA, nor is it new. Centuries ago, satirist Jonathan Swift made light of similar silliness in the classic Gulliver’s Travels.

Yet, such perceived differences actually are of great consequence to lots of people. Whether real or imagined, material or superficial, presumed differentiations often are taken very seriously and can have enormous economic and professional impacts. Consider, for example, how picking just the right terms for ads, titles, and web sites affects sales of books, training, and consulting.

Po-tay-to, Po-tah-to

Now that we say it out loud, it’s fairly easy to recognize some of the significant consequences when similar things are called by different names and when different things are called by the same names. Yet, few are aware that in the U.S. and Canada, the International Institute of Business Analysis (IIBA) and its various certifications predominate, whereas in Europe, the International Requirements Engineering Board (IREB) holds similar status. Each is convinced of their unique niche, but darned if I can see the difference. And, yes, a couple of other contenders further muddy the waters.

Where It Really Matters

In the final analysis, whether you call it RE, BA, or BS is superficial form and matters mainly to the handful of brand promoters like IREB and IIBA. However, difficulties differentiating content substance can have a much less evident, but unfortunately far greater and more insidious direct and indirect impacts.

We’re familiar with the physical science concept of inertia, wherein a body in motion tends to stay in motion and a body at rest tends to stay at rest. However, inertia also pertains to thinking. It’s very hard to overcome entrenched ideas, and institutions often create obstacles to further impede challenges to their vested ways of thinking. Establishing and defending a brand takes advantage of such inertia.

We still regularly see news reports of those in power, or seeking power, torturing and murdering people whose ideas are deemed to threaten the establishment/brand—just as they’ve done for dozens of centuries. Yet, once-heretical ideas can become mainstream, often though only after extended sacrifice by initial adopters.

While not happening to the same draconian extent in the BA community, nonetheless both conscious and unconscious forces continually curtail ideas that are counter to brands’ favored conventional BA wisdom. BA has become big business, relying largely on brands to sell products and services. Though probably not apparent to consumers, promoters quite consciously guard BA brands behind the scenes through economic, social, and legal pressures against their few generally easily-identified competitors.

Advertisement

Unconscious Content Confusion

In contrast, content confusion directly affects a somewhat larger but still small group of BA authors and trainers like me. More importantly, though, content confusion can indirectly affect the full BA community by suppressing innovation and awareness of different and potentially better ideas. Content confusion is especially prevalent because it’s seldom recognized or conscious.

Stories of intrigue often advise “following the money.” In BA, money mainly comes from training, consulting, and publishing. Overwhelmingly, buyers choose which BA products and services to buy based on brief titles and descriptions. Not surprisingly, most BA courses and books have similar names. A search for a particular BA topic keyword on Google or even a training vendor’s website implies all displayed courses/books have comparable content.

Indeed, many BA products’ content essentially is interchangeable. Sometimes that’s intended, such as for courses/books to prepare one to pass a particular certification exam. More often it’s unintended, typically occurring because most authors/trainers simply repeat what they’ve learned from other authors/trainers. That’s not my content.

Better-known authors join to institutionalize their repeated content in various BA brands’ bodies of knowledge. Consequently, I find competing brands’ content virtually indistinguishable except for stylistic variations and a few consciously coined signature terms. Most brands avoid confronting competing brands directly, I’d say somewhat cynically because they can’t convincingly describe let alone set apart their differences.

Different authors/trainers do vary in how they present their common content, which presumably makes one product more interesting or informative than others. Over time, popularity and search engine rank should reflect superior products. However, inertia and promotion also affect product perceptions. Since few buyers look past the first page or even first item of a search, prominent item position is mainly what’s reinforced.

Moreover, titles and keywords that buyers think to look for are unlikely to reveal products that have different or innovative ideas content. Even the brief descriptions of similar-sounding products often cannot convey meaningful content differences.

Buyers sometimes rely on sales representatives to explain respective products’ pros and cons. With perhaps 1000+ titles for sale in their catalog, sales reps cannot actually be familiar with more than a few, and may not truly understand them, let alone how their content differs or why it matters. Not surprisingly, sales reps usually stick with pushing the same popular products, sometimes at the expense of possibly preferable ones.

Confusion’s Catch 22

Indeed, parts of my courses and writing are like what others also say. It would be foolish not to gain guidance from colleagues and other experts. However, mostly what’s the same is general concepts and techniques. On the other hand, my work is differentiated by key central models and methods which I developed personally over many years performing real projects of business significance for leading organizations.

Certainly, many people have project experience and maybe even have innovated; but I’ve seen few who critically understand what they’ve done and even fewer who can extend it to benefit others. Besides having a propensity for trying to figure out how and why things work, I’ve been fortunate to build perspective from encountering similar situations several times and having the occasion of creating courses to analyze and translate them into meaningful models and methods others can use to advantage.

For example, my BA work focuses on discovering what I call REAL business requirements, which are very different in ways that make important differences from the “requirements” most authors, trainers, and brands focus on.

Yet, few buyers, sales representatives, or even other BA authors/trainers recognize that my courses/writings (including also Proactive Testing™, REAL ROI™, and Beyond the Textbook™ acquisition) differ from most others, let alone understand the differences or appreciate why my materials are so much more valuable. Differences in titles and descriptions just don’t register with someone until after they’ve learned about my approaches; and they won’t learn about my approaches because the differences don’t register with them. Explanations like this are so important for building awareness.

REAL Business Requirements

Other authors, trainers, and bodies of knowledge do use the term “business requirements,” almost always to mean objectives and purposes/desired value. In contrast, REAL Business Requirements are business deliverable whats that when satisfied achieve objectives and thereby provide value. That’s a real difference.

REAL Business Requirements deliverable whats are satisfied by some product/system/software, whose product requirements/features are ways how presumably to satisfy the whats. Other authors, trainers, and bodies of knowledge focus almost entirely on product/system/software requirements hows, which do not themselves provide value.

Creep, changes to requirements after they supposedly have been settled, is a major cause of project overruns. Conventional wisdom is that creep is caused by requirements, meaning product requirements, which are not sufficiently clear or testable. Testability is largely a function of clarity.

While clarity and testability are important, much of creep occurs because the product requirements, regardless how clear and testable they are, fail to satisfy the REAL business requirements, mainly because the REAL business requirements have not been defined adequately, in turn because conventional wisdom mistakenly thinks that product requirements are THE requirements.

Thus, the key to reducing creep is first to discover the REAL business requirements deliverable whats that provide value when satisfied. Then, define the requirements/features of a product/system/software way how to satisfy the whats.

Traditional BA courses and writings don’t teach this because their authors don’t know it. When I present these ideas to a group of practicing business analysts, about half seem to have aha moments and make comments like, “Now I understand why I’ve been having requirements problems all these years.”

Ironically, many BA guru authors/trainers don’t seem able to understand the differences. Some folks would say it’s because they have a vested financial interest in the traditional model focused on product requirements that they sell. I think it’s more likely their mindsets are so firmly established that they cannot mentally accept something fundamentally different. I think that’s their loss, and more importantly also the BA community’s loss.

In addition to explanations like this to create awareness my courses do differ, I’ll more consistently include hopefully differentiating terms in course titles, such as REAL business requirements, and explain their important differences in course descriptions.

Who is Who: The Importance of an Org Structure when Delivering Projects

Written by Frankie Mouzon on . Posted in Articles.

When starting a new job or project, it is very important as a Project Manager or Business Analyst to have a good idea of how an organization or business operates.

This helps navigate the internal & external ways of the business, and understand how it affects the customer base. I currently work in the hospital healthcare industry, which acquires several hospitals each year. The more companies that the business acquires, there is a high chance that there will be more growth, responsibility, & opportunities (including problems), but the business can easily become chaotic if not properly structured. On my first day of the job, I did the typical project manager request by asking for an organization structure. Unfortunately, my request was rejected because employees either left, were laid off, promoted, or moved to different departments due to another recent acquisition purchase. As a result, I did not know who to go to for information or to execute certain tasks. Org charts are vital for the following reasons:

  1. It helps Project Managers & Business Analysts understand the different functions throughout the business, the team, and team members.
  2. It is very important to understand who needs to be involved or the appropriate audience when it comes to sharing information for projects or initiatives.
  3. There is always room for improvement.

If organization structures were more emphasized, there would be much more efficiency, productivity, and less stress & chaos for employees throughout the business.

Knowing Your Industry & Business

Knowing your industry and business are super-beneficial in so many ways.

  1. It helps boost productivity & performance. By understanding the organization and its structure, the Project Manager and Business Analyst will know exactly who to go to for tasks and get stuff done, instead of going around in circles. It is all about delivering & proving the return of investment (ROI) based what you delivered.
  2. It allows you to network outside your team and gain relationships. You probably hear this often, but your network is your net worth (internally [within your team and organization] & externally [the industry & working with vendors]). In a perfect world, everyone has a role and numerous responsibilities, and they are obligated to make sure they uphold their responsibility no matter what. But in the real world, that is not always the case. If a team member on a project does not know you well enough, there is a chance that he or she will be less motivated or enthusiastic to work with you, or even go above and beyond the call of duty to get last-minute extra tasks done for the project. It is also important for the organization to know who you are. You are a great professional, but now it is time for everyone else to know that you are great! Your reputation is everything. If no one knows who you are besides your team, what reputation do you really have?
  3. Exposure is key to taking advantage of new opportunities and gaining new insights of what is going on in the organization. If you constantly perform to your greatest height, and continue to have a great reputation across the organization, people will come to you for input & new opportunities. Being a Project Manager or Business Analyst is a wonderful role with great rewards, but always allow yourself to grow when the opportunity knocks. As human beings, we must challenge ourselves often in order to grow and not become stagnant. As you accomplish a major challenge, another will come and that is how you improve physically, mentally, and spiritually. Always aim higher and be better! In addition, if there is a change in operations or process for a department and you have a good working relationship, there’s a high chance that information will be communicated to you, which you can communicate to your team. Yes, spread the word! From a team perspective, you are trustworthy and reliable when it comes to your say-do ratio and knowledge of information.
Advertisement

Putting the Pieces Together

During the initiation stage of a project after getting the project charter approved, it is the job of the Project Manager and/or Business Analyst to identify the stakeholders, and determine their expectations, influence, & impact of the project. In order to know the major and minor stakeholders, you must understand the structure, culture, existing systems, and project management processes of the company. Below are a few pointers when it comes to identifying the right stakeholders:

  1. Understand the problem that needs to be solved. This is very important because it provides an opportunity to understand the current state and the people who are involved in the current process that needs to change. By understanding the current state & pain points, you automatically get buy-in from the end-users, and it is perceived as if you are intrigued and determined to be solving the problem. Believe it or not, this will be in your favor as the project continues. After determining the people involved in the current process, they should be listed in the stakeholder register and evaluated based on their impact & influence of the project. Most importantly, they must be kept in the loop of what’s going on throughout the project no matter if it is a weekly or monthly project status update &/ or meeting.
  2. Ask your business sponsor and/or champion. Most of the time, the business sponsor/champion will let you know the details of the problem &/ or project that no one else will know or share, including the stakeholders who need to be involved. As you list these different stakeholders, try to understand their current role & responsibilities, and how they fit into the current business problem(s) that need to be resolved. By doing so, it will show their value & impact to the project. A “good” business sponsor/champion will be your best ally when it comes to the project, because they will provide as much support as possible to solve the problem because of the value added to the business.
    BUILD A RELATIONSHIP WITH YOUR SPONSOR/CHAMPION! I cannot emphasize this enough. In order to build a relationship, you must gain trust. In order to gain trust, having a 100% say-do ratio is necessary. Always deliver what you say you are going to do, and then they will like you. Also, treat your champion how you want to be treated. Key words to apply are truth, respect, enthusiasm, reliability, inclusion, & help.
  3. After gathering your initial list of stakeholders, sit down with your manager and review the list to get feedback. This is very important to fill any gaps. Your manager is in that position for a reason, so use them for your benefit. If you are successful, your manager is successful. It is a win-win situation!

There are ALWAYS Opportunities for Improvement

Two of the greatest traits that a Project Manager or Business Analyst should have is being inquisitive & innovative by looking at how things are currently done and can be improved. As you get a better understanding of the organization, and the roles & responsibilities of all teams and their team members, ask questions. Why is the person doing this task? Why is the person doing the task this way? Is there an easier way to get the same output? As Project Managers & Business Analysts, it is our sole responsibility to create value, efficiency, and productivity throughout the entire organization. This might not be easy to get the top people (executives, senior management) on your side, but this is where your influencing skills apply.

Although eliminating waste and creating value should be coming from the top-down, that is not always the case. There are times where you must step up and be a change leader. Yes, you will have to open your mouth & communicate this to senior management, but you can back it up with facts, pain points that affect productivity, the potential solutions, and quantitative benefits (dollar amounts is highly suggested) when the pain points are resolved by one or more a combination of the solutions. By including these factors to your story while presenting the opportunity, you can make a difference & also shift the company culture to innovating constant improvement. So, let’s put on our capes and become change leaders!

Sum It Up

Organization structure is necessary in order to complete projects successfully. According to Rita Mulchay’s PMP Exam Prep Eighth Edition, the Project Manager must “determine company culture and existing systems”. Existing systems include an org chart where you must understand the roles and responsibilities for every team and team member. For business analysts, in order to conduct a successful strategy analysis, they must have the organization chart as part of understanding the current state. If there is no order, there is chaos; and this applies to projects or initiatives, which create tons of value.

Who is Who: The Importance of an Org Structure when Delivering Projects

Written by Frankie Mouzon on . Posted in Articles. 1 Comment

When starting a new job or project, it is very important as a Project Manager or Business Analyst to have a good idea of how an organization or business operates.

This helps navigate the internal & external ways of the business, and understand how it affects the customer base. I currently work in the hospital healthcare industry, which acquires several hospitals each year. The more companies that the business acquires, there is a high chance that there will be more growth, responsibility, & opportunities (including problems), but the business can easily become chaotic if not properly structured. On my first day of the job, I did the typical project manager request by asking for an organization structure. Unfortunately, my request was rejected because employees either left, were laid off, promoted, or moved to different departments due to another recent acquisition purchase. As a result, I did not know who to go to for information or to execute certain tasks. Org charts are vital for the following reasons:

1. It helps Project Managers & Business Analysts understand the different functions throughout the business, the team, and team members.
2. It is very important to understand who needs to be involved or the appropriate audience when it comes to sharing information for projects or initiatives.
3. There is always room for improvement.

If organization structures were more emphasized, there would be much more efficiency, productivity, and less stress & chaos for employees throughout the business.

Knowing Your Industry & Business

Knowing your industry and business are super-beneficial in so many ways.

1. It helps boost productivity & performance. By understanding the organization and its structure, the Project Manager and Business Analyst will know exactly who to go to for tasks and get stuff done, instead of going around in circles. It is all about delivering & proving the return of investment (ROI) based what you delivered.

2. It allows you to network outside your team and gain relationships. You probably hear this often, but your network is your net worth (internally [within your team and organization] & externally [the industry & working with vendors]). In a perfect world, everyone has a role and numerous responsibilities, and they are obligated to make sure they uphold their responsibility no matter what. But in the real world, that is not always the case. If a team member on a project does not know you well enough, there is a chance that he or she will be less motivated or enthusiastic to work with you, or even go above and beyond the call of duty to get last-minute extra tasks done for the project. It is also important for the organization to know who you are. You are a great professional, but now it is time for everyone else to know that you are great! Your reputation is everything. If no one knows who you are besides your team, what reputation do you really have?

3. Exposure is key to taking advantage of new opportunities and gaining new insights of what is going on in the organization. If you constantly perform to your greatest height, and continue to have a great reputation across the organization, people will come to you for input & new opportunities. Being a Project Manager or Business Analyst is a wonderful role with great rewards, but always allow yourself to grow when the opportunity knocks. As human beings, we must challenge ourselves often in order to grow and not become stagnant. As you accomplish a major challenge, another will come and that is how you improve physically, mentally, and spiritually. Always aim higher and be better! In addition, if there is a change in operations or process for a department and you have a good working relationship, there’s a high chance that information will be communicated to you, which you can communicate to your team. Yes, spread the word! From a team perspective, you are trustworthy and reliable when it comes to your say-do ratio and knowledge of information.

Advertisement

Putting the Pieces Together

During the initiation stage of a project after getting the project charter approved, it is the job of the Project Manager and/or Business Analyst to identify the stakeholders, and determine their expectations, influence, & impact of the project. In order to know the major and minor stakeholders, you must understand the structure, culture, existing systems, and project management processes of the company. Below are a few pointers when it comes to identifying the right stakeholders:

1. Understand the problem that needs to be solved. This is very important because it provides an opportunity to understand the current state and the people who are involved in the current process that needs to change. By understanding the current state & pain points, you automatically get buy-in from the end-users, and it is perceived as if you are intrigued and determined to be solving the problem. Believe it or not, this will be in your favor as the project continues. After determining the people involved in the current process, they should be listed in the stakeholder register and evaluated based on their impact & influence of the project. Most importantly, they must be kept in the loop of what’s going on throughout the project no matter if it is a weekly or monthly project status update &/ or meeting.

2. Ask your business sponsor and/or champion. Most of the time, the business sponsor/champion will let you know the details of the problem &/ or project that no one else will know or share, including the stakeholders who need to be involved. As you list these different stakeholders, try to understand their current role & responsibilities, and how they fit into the current business problem(s) that need to be resolved. By doing so, it will show their value & impact to the project. A “good” business sponsor/champion will be your best ally when it comes to the project, because they will provide as much support as possible to solve the problem because of the value added to the business.

BUILD A RELATIONSHIP WITH YOUR SPONSOR/CHAMPION! I cannot emphasize this enough. In order to build a relationship, you must gain trust. In order to gain trust, having a 100% say-do ratio is necessary. Always deliver what you say you are going to do, and then they will like you. Also, treat your champion how you want to be treated. Key words to apply are truth, respect, enthusiasm, reliability, inclusion, & help.

3. After gathering your initial list of stakeholders, sit down with your manager and review the list to get feedback. This is very important to fill any gaps. Your manager is in that position for a reason, so use them for your benefit. If you are successful, your manager is successful. It is a win-win situation!

There are ALWAYS Opportunities for Improvement

Two of the greatest traits that a Project Manager or Business Analyst should have is being inquisitive & innovative by looking at how things are currently done and can be improved. As you get a better understanding of the organization, and the roles & responsibilities of all teams and their team members, ask questions. Why is the person doing this task? Why is the person doing the task this way? Is there an easier way to get the same output? As Project Managers & Business Analysts, it is our sole responsibility to create value, efficiency, and productivity throughout the entire organization. This might not be easy to get the top people (executives, senior management) on your side, but this is where your influencing skills apply.

Although eliminating waste and creating value should be coming from the top-down, that is not always the case. There are times where you must step up and be a change leader. Yes, you will have to open your mouth & communicate this to senior management, but you can back it up with facts, pain points that affect productivity, the potential solutions, and quantitative benefits (dollar amounts is highly suggested) when the pain points are resolved by one or more a combination of the solutions. By including these factors to your story while presenting the opportunity, you can make a difference & also shift the company culture to innovating constant improvement. So, let’s put on our capes and become change leaders!

Sum It Up

Organization structure is necessary in order to complete projects successfully. According to Rita Mulchay’s PMP Exam Prep Eighth Edition, the Project Manager must “determine company culture and existing systems”. Existing systems include an org chart where you must understand the roles and responsibilities for every team and team member. For business analysts, in order to conduct a successful strategy analysis, they must have the organization chart as part of understanding the current state. If there is no order, there is chaos; and this applies to projects or initiatives, which create tons of value.

Let’s work together

Register
Contribute
Advertise
Contact Us

© PM Times.com 2023

Privacy Policy | Terms of Use

Macgregor Communications