Requirements Archives - Page 2 of 49 - Project Management Articles, Webinars, Templates and Jobs

Achieving Quality Performance and Results

Written by George Pitagorsky on September 27, 2022. Posted in Articles.

Projects are performed to deliver quality products/services and satisfy budget, and schedule expectations. This article focuses in on quality deliverables, their relationship to quality performance, and the quality management process that seeks to ensure that quality criteria are met.

The quality of performance (the work required to deliver results) and the quality of the outcome (a service or product) are intimately related. Every outcome is the result of performance, a process. High quality performance delivers high quality outcomes. The process is the key. If it is a good one, it makes sure that quality is defined and mutually understood by stakeholders and that “critical assessment” is done with positive attitudes.

Quality Management

If you can’t describe what you are doing as a process, you don’t know what you’re doing.
W. Edwards Deming

Quality management (QM) is a process. It is well described in PM standards, yet poorly defined quality criteria and personal reactions to critical assessment, if it is done at all, get in the way of applying quality management principles.

The goal of quality management is to improve the probability of achieving quality outcomes. It makes sure results are being developed in a way that leads to success and whether success has been achieved.

Effective quality management relies on a simple model:

Set quality criteria
Define the process for controlling quality, including roles and responsibilities
Assess performance against the criteria
Learn
Adjust
Continue.

It is a variation on the classic Plan, Do, Check, Act (PDCA) model. So simple and rational. Yet, there is still need to raise quality consciousness and overcome the obstacles to a practical effective quality management process.

What Gets in the Way?

There are three primary obstacles to achieving quality outcomes: lack of clear definition of quality attributes (specifications), poor collaboration, and resistance to critical assessment. These are strongly influenced by people’s attitudes (mindset) and their setting – organizational values, processes, and relationships.

Fuzzy Specs – Lack of Objective Criteria

If you and other stakeholders don’t know what quality is how can you achieve it?

Clarity and agreement regarding what you and other stakeholders mean by quality in each case, avoid subjective expectations and the inevitable conflicts that occur between those who deliver and those who receive and/or assess results. One person’s sense of quality is often not the same as another’s, so it is important to get into details about what is expected.

This obstacle seems easy to overcome. All you have to do is specify the product and performance with objective quality criteria.

But anyone with experience knows that it is not so easy. It takes time, skill, effort and most of all collaboration among performers requirements analysts, quality management staff, users, and clients.

For example, performance quality can be defined in terms of error or defect rates and productivity. Product quality, in terms of measurable attributes such as resiliency, duration, reliability, and customer satisfaction. Service quality can be specified with parameters for response time, customer satisfaction, etc.

Defining requirements takes time and effort. And it is hard to specify the less quantifiable quality criteria like color and texture, look and feel, refined finishing, absence of subtle flaws.

Clients often say that they’ll know quality when they see it. That tells you that when it comes to specifying quality look and feel requirements, it is best to use examples, CAD renderings, prototypes, and an agile approach.

Collaboration

Collaboration is the key to success. A collaborative process helps to get everyone to own the definition and to make sure that what is expected is feasible and fits within time and cost constraints. When quality specifications are set by the client without involvement of the people who must deliver and test, the stage is set for conflict and unnecessary pressure on the delivery team.

In a collaborative process, the delivery team can give feedback about the costs of quality features while clients and others can bring in cost of quality (for example the cost of errors and maintenance) to enable the team to justify costs related to higher quality. The quality control people can set expectations and engineer the best testing approach.

Together, stakeholders, deliverers, clients, quality assurance and control staff, users agree upon a set of criteria that is likely to be met with expected levels of cost, time, and effort and on the process they will use to make sure quality is achieved..

Whether you are taking an agile approach in which the team is working together to evolve the product throughout the project, a hybrid approach, or a more waterfall like approach, the time and effort required for collaborative work more than pays off by minimizing unnecessary conflict and unmet expectations.

Resistance to Assessment

Setting criteria is critical. Once set, assessment is a natural, obvious follow up.

How hard could that be? You just measure interim and final outcomes against quality criteria, when there is a diversion, determine cause, decide how to proceed?

However, overcoming resistance to assessment is even more difficult than overcoming the “fuzzy specs” obstacle. Here we are confronted with cultural, procedural, and psychological barriers.

The psychological level is the most important. Many people take criticism of their work as personal assault. There may be cultural issues regarding critical assessment. Some fear being fired. Old personal issues are triggered. Some fear saying something that might upset key performers and co-workers. Sometimes performers get angry at testers and reviewers when they come up with errors or performance issues.

Its complex. The secret ingredient is clear communication regarding what assessment is all about and how to do it in a way that continuously reinforces the sense that criticism is a positive thing that contributes to ever increasing quality. Acknowledge the obstacles.

If below par performance is not confronted it will continue. Individuals will not have the opportunity to learn and improve their performance. If errors and omissions are not discovered during controlled testing, they will be discovered after the product is released for use, at a far higher cost than if detected earlier.

Quality Process

Quality process leads to quality outcomes. We are addressing the quality management process. Its success relies on mutual understanding and collaborative effort by stakeholders. Together they address the obstacles of fuzzy specifications, lack of collaboration, and resistance to critical assessment.

Spend the time and effort on continually refining the quality management process to avoid unnecessary conflict, dissatisfaction, and poor-quality outcomes. Start with a review of your current situation – Is there a documented process? Is everyone happy with the way things are being done and the results?

See the article The Key to Performance Improvement: Candid Performance Assessment

https://www.projecttimes.com/articles/the-key-to-performance-improvement-candid-perfromance-assessment/

Exceeding Expectations is a Quality Killer

Written by Gratien Gasaba on August 9, 2022. Posted in Articles.

Do you remember a time when you were hungry, and once your favorite food was brought, you couldn’t help but consume only part of it? Why didn’t you eat it all, given it is your favorite food? The answer is very easy. As you eat, hunger starts to disappear and immediate interest in the favorite food starts to reduce until it disappears. At the time you feel satisfied with already eaten food, swallowing an extra unit will be harmful. How would you feel if a friend of yours insist that you should eat that extra quantity of that delicious food?

The project management profession is full of similar stories. In the project management profession, stakeholder engagement is paramount to the project’s success. The purpose of fully engaging stakeholders is to ensure their satisfaction.

Why do stakeholders’ expectations matter?

Project management is one of the few jobs that are likely to suffer less from robotization. This is because the project management job involves interacting with people to understand their needs to serve them better. The business case at the origin of a project ensures the business bottom line is at the service of key stakeholders essentially customers, end-users, suppliers, and the sponsor. Consistency in project management consists of regularly testing the correspondence between the business case and stakeholders’ expectations. This test helps ensure that the project implementation serves the needs and wants of stakeholders since a project, regardless of the industry, should be pro-people. By trying to develop a new product, service, or result, a project exists to serve the needs or expectations of key stakeholders mainly customers and end users.

Benefits realization: the total utility for stakeholders

As rightly put in the previous section, a project exists to serve the needs of key stakeholders. Customers and end-users invest their capital into a project expecting that the ultimate result will make them better off or happier. When a project manager or a project team member strives to meet stakeholders’ expectations, she/he assumes that by doing so the beneficiary stakeholders will get more enjoyment or happiness from the project results. Microeconomics teaches us that this satisfaction, or happiness felt by the consumer, or the stakeholder in the project management language, is also known as utility in the disciple of Economics. Utility function has been largely studied by microeconomics scholars and they postulate that the consumer will seek to maximize the utility derived from consumer goods and services. If project team members stop here, they will spare no effort to find how they can exceed customers’ expectations. However, Microeconomics arrived at a conclusion that for a single good or service (project result in this case), consumers maximize the enjoyment or total utility when marginal utility becomes zero, as its curve reaches the flexion angle. At this point, the total utility starts to decline, and the extra unit of goods consumed starts harming the consumer as illustrated in the following graph. Remember the old saying that “too much is always bad”.

Navigating the project complexity to meet stakeholders’ expectations

In light of the above discussions, the work entrusted to the project manager is not straightforward. It is full of changing individual and organizational behaviors, a dynamic system behavior resulting from connectedness and interdependency of project elements that interact to bring about change as well as ambiguity stemming from unclear cause-and-effect relationships, emergent issues, and situations that can be interpreted differently.

Stakeholders’ expectations are embedded in individual and organizational behaviors, which, as mentioned above, are changing. The changing nature of stakeholders’ expectations makes it difficult to identify them. Targeting to exceed stakeholders’ expectations will bring more complexity as, to be safer, it would be built on assumptions of increasing marginal utility which is a very rare situation. Proponents of the postulate of exceeding stakeholders’ expectations base their view on the assumption that the expectations in question are less than the maximum total utility or benefit that can be obtained from the project. However, this is not always true, given that history is full of examples of overambitious stakeholders. In addition, this assumption of a sober and realistic stakeholder tends to forget other aspects that make project management complex namely the limited resources, emerging issues, stakeholders’ changing behavior, and most importantly the diminishing marginal utility of most of the project results as well as their opportunity cost.

To solve this problem, the adaptive approach in project management proposes to regularly check stakeholders’ expectations and adjust targets to a desired, justifiable, and affordable level. By adjusting project targets, the project team will hence deliver to newly identified stakeholders’ expectations rather than exceeding them. The adaptive approach will embrace the continuous improvement practice in which the regular assessment of stakeholders’ expectations will be the mandatory entry point.

Ethics and exceeding stakeholders’ expectations

In most situations, the project team members work as agents on behalf of the sponsor who is the principal. They receive the project implementation mandate from the sponsor or the customer. The project team is selected based on its skills, experience, exposure, and network, assumably required for successful project implementation. As they carry out their duties, team members obtain specific information on the project. Ethics requires the project team to share specific information with relevant stakeholders to ensure informed decision-making. Before delivering beyond expectations, a team member that behaves ethically will check with the concerned stakeholders if doing so will be beneficial for them. If the stakeholder confirms his interest, then the project team will be delivering on revised stakeholders’ expectations rather than beyond expectations.

If on the contrary, the project team goes ahead and delivers the unilaterally revised targets without confirmation from concerned stakeholders, this will sound unethical because one would ask why hiding good things, and the moral hazard can easily slip in this behavior.

Conclusion

As a continuous improvement practice, it is recommended to regularly check stakeholders’ expectations to deliver just on it. It goes without recalling that “too much is always bad”.

Design Thinking and Project Management

Written by Giovanny Guillen on June 1, 2022. Posted in Articles.

What is Design Thinking?

Design thinking is a methodology that was created by Stanford University professor Tim Brown and IDEO’s CEO, an innovation agency where they wanted to improve the service to their customers, from an empathy approach. Every time, the method proposed in Design Thinking is being used all over the world, especially in organizations that want to solve problems, focused on clients, based on ideas, proposals, and experimentation, above all.

This dynamic occurs even when the ideal of the final product or deliverable is not yet clear, but if the problem is clear and the work of experimentation with the final customer is enhanced. This way of solving problems has stages, but without a doubt its basis is the focus on the needs of the client, empathizing, observing, evaluating, creating prototypes (experimentation), testing, getting feedback, and improving the product.

This process allows sustainable growth and is based on teams from multiple disciplines, to achieve products or services, technically feasible, that meet the expected and within the resources available.

The process.

Through the different design thinking phases, we can use a series of technics and tools that allow us to develop new products and services, from understanding problems or needs to prototype, business model, evaluating alternatives, client feedback, etc. It is important to punctuate that this is an iterative process.

Figure 1. Design Thinking Steps

The stages are briefly described for comprehension purposes; however, I will focus on the “Empathize” stage and its tools to improve the lifting of the client’s need, their desires, knowing their “pain” and how to plan possible solutions. Independent of the project approach: predictive, agile, or hybrid.

Empathize:

This stage is perhaps the most relevant, because it focuses on understanding as a team and individually, the desires and incentives that the client has, beyond the need itself. Here is much of the success of this method, as it drives you to know customers or end-users deeply. Considering, of course, the “hard” data, figures, fixed strategy, business plan, which are important because they are the “context” of the problem, but it is not the primary objective of empathizing.

This empathy is achieved by engaging with end-users or customers. Getting your point of view and ideally living it. Several tools and techniques of this stage are those that I will deepen in this article.

Define:

In the first stage, we should be able to obtain the main problems posed by the user/client with the necessary depth. It is then necessary to evaluate the information obtained and detail the one that contributes to a greater extent to really know the users. Here are defined those hypotheses that present greater opportunities to generate value to the client when solved.

Ideate:

It is now up to elaborate ideas for the problems selected from the previous phase, the focus is to look for a range of solutions, there is no “bad idea”, the more alternatives the better for the process. Brainstorming is crucial at this stage, the best one for the team and its characteristics are sought, considering of course the users/customers. As the name suggests, in this phase the solution ideas are worked on, and collaboration and participation of all team members are encouraged.

Prototype:

As the name implies, here ideas are transformed into prototypes. It pursues further experimentation by the team and customers. Prototypes can be made with common materials such as paper, cardboard, Lego blocks that reflect functions of the final product. Or in the case of digital prototypes, app demo.

Testing:

Here the tests with the prototypes made are carried out and the users/client are asked for their feedback regarding the experimentation with the prototypes. This stage allows to identify improvements, failures, deficiencies, good points that must be maintained, etc. Ideal to maintain as a team a receptive look at the interaction of users with the prototype, answer inquiries and documents.

Evaluate:

Here it is necessary to analyze the errors, and observations obtained from the previous stage, looking for the points of improvement of the product. This can lead us to go back to previous stages with the improved products and experiment again until we get to the closest thing to the product desirable by the user/customer.

Design Thinking Tools.

Independent of the project approach: predictive, agile, or hybrid. Especially for user “requirements” or “stories”, the following tools or techniques add a lot of value in complementing and fully identifying the customer’s desires.

Empathy Map: this is one of the most useful and applicable tools to get to know our customers/users in depth. It allows delivering a global vision of the aspects of the “human being” behind the client.

It is a canvas like the one presented below, which can of course be complemented with the areas that as a team we determine valuable for our process, this gives us benefits such as:

- Improve the understanding of our customers or users.
- Have a dashboard view of customer needs
- Land expectations and document them.
- The visual saves a thousand words.
- Develop the products considering the map obtained.
- Enhance the lifting of requirements and enrich user stories.
- Allows you to engage in the client’s “pain” and experience their concerns.

Figure 2. Empathy Map

Job Shadowing or Observation: focuses on observation, supported by an interview with stakeholders or users who carry out the activities of the business flow that is part of the client’s environment. Example: A shoe factory would mean observing (not just talking or interviewing) all those roles that are part of the required business flow. In IT or Technological industries, for example, it is common for metrics such as:
- A number of interactions carried out by users in the system or application they use as part of the process to be surveyed.
- Failures or points of failure of the system or application.
- Execution process times of the functionalities of the system or application.
- Of course, everything is related to the customer experience.

Benefits: observing that it goes beyond the story, the daily operation of the organization (in-situ), allows to know, document, and see the critical points of the flow and what can be improved. There is no better feedback than from the first source, experiencing and evidencing the activities that will be the focus of intervention of our project, allows us in addition to documenting the current flow, to know the “pains” of the user (client) and their expectations.

Actors Map: it is a graphic representation, very simple, that allows concentrating in the same plane, the interactions, degree of involvement, and the relationships of the actors that relate to our main client. All this is in the context of the problems that are being tried to develop.

There are several ways to represent this map, the example described below is circular, which is segmented into three parts depending on the areas of the customer relationship, segmentation is according to our need.

Figure 2. Actors Map

Source: http://tynerblain.com/blog/2007/03/13/visualize-stakeholder-analysis/

Another important point is that the gaze of actors is also equivalent to those interested in the project such as people or institutions, private or public.

They participate in this diagram:

Direct actors: they interact directly with our client (in the center). We can associate them with greater or lesser influence.
Main actors: they are related and interact with our main client; they have lower interaction, and you don’t have so much control over them.
Secondary actors: they are related and interact with our main client, in a distant way, but may or may not have influence and relevance. They are unpredictable.

Design Thinking in Project Management

In projects, independent of the approach, we can innovate, with tools or techniques that are not necessarily the traditional or usual ones for our projects. Precisely in times where the dynamism of the market and the behavior of our customers, we must have the ability as a team and organization, of course, to adapt and use those techniques that facilitate our day to day and allow us to get to know our users or customers who are finally the main focus of our activity.

In this context, we can use this tool to define:

Customer needs
The product features
The project scope
Design business process
The IT architecture
Requirements analysis

This approach helps us to identify stakeholders, improve the process to select projects, reduce conflicts, innovate in a changing world, solve complex problems, and we can work to satisfy needs and increase value to the business.

Critical Skills Needed for Project Success

Written by Elizabeth Larson on November 2, 2021. Posted in Articles.

Part 1 – Elicitation

This article is the first in a series I’ll be writing about critical skills that all project managers (PMs) and business analysts (BAs) need for success. We need these skills regardless of the type of project we’re on, the industry we’re in, the technology we use, or the methodology we follow. Each of these skills requires a combination of what are commonly called hard skills with those needed to work effectively with others.

This first article is about elicitation. It seems easy. After all, what’s so difficult about asking stakeholders questions? Elicitation, of course, is far more than the questions we ask. When all is said and done, it’s about learning. We learn what our stakeholders want, what they need, and hardest of all, what they expect by asking really good questions and listening to what they have to say with great attention. It’s tricky, though. We can’t do what I did early in my career when I tried to develop a list of requirements by introducing myself and asking what the stakeholders’ requirements were, what they really needed, and what they expected by the end of the project. Simply put, we won’t learn enough to create an end product that they’ll be happy with.[i]

What makes the elicitation process so hard? Here are several pitfalls.

Common Pitfalls

#1 – Missed expectations

Expectations are requirements, but they’ve never been stated. Therefore, we cannot get expectations by asking about them. Our stakeholders don’t think to mention them, and we don’t think to ask about them. I didn’t know about hidden requirements early in my career when I asked the questions like those noted above. Another problem– my focus was specifically on the future state solution. I asked for the features and functions, documented them, and got stakeholder approval. Then the development team built the final product according to the specifications with the inevitable result—a lot of stakeholder complaints.

#2 – People fear the future state.

This major pitfall is hard to overcome for many reasons. Some stakeholders are comfortable with their current state and don’t want to learn or train on the new processes and automation. Others are concerned for their jobs. Still others have a stake in the existing ways – perhaps they were part of its development or a known expert on its use. Whatever the reasons, the fear of the future state can make elicitation difficult.

#3 – The time trap

Many of us are often under so much pressure that we don’t have time to dig deep. We gather some high-level requirements, but we don’t have time to uncover the expectations. And even if we have time, which is rare, many of our stakeholders don’t. Many are available for an initial set of sessions, but interest wanes as the difficult detailed meetings drag on.

So, what can we do? Here are 3 tips for successful elicitation.

Tips for Successful Elicitation

Tip #1 – Use a variety of elicitation techniques

The first tip for uncovering expectations is to use a variety of elicitation techniques. That’s because each technique that we use uncovers a different aspect of the requirements. Here are some examples.

Process modeling. This has always been one of my favorite techniques. It documents how people get their jobs done. But as with all elicitation, it’s not easy. For example, one of the most difficult aspects about process requirements is that stakeholders argue over where to begin and where to end and how the processes fit together. Using different process models helps avoid this contention. SIPOCS (suppliers, inputs, process, outputs, customers) help narrow the scope of each model and swim lane diagrams help visualize how the processes fit together.
Data modeling. Process modeling is great, but people need information to get their work done. Data modeling helps us figure out what information supports each process step. It also provides business rules and is invaluable on our AI initiatives.
Use cases. These models help us understand how our stakeholders want to use the final product. They provide not only the scope, but all the functionality of the solution. And use cases, if completed thoroughly, turn into test cases.
Prototypes show what the final solution will look like.
Brainstorming yields the power of the group, while one-on-ones often reveal what stakeholders really think.

Tip #2 – Ask context questions

A context question is one that surrounds the solution that we’re building. While we do need to ask questions about the solution’s features and functions, such questions do not provide the complete picture.

I like to group context questions into four categories of questions:

These questions relate to what’s happening outside the organization and include questions like demographics, language, weather, technology, and compliance/regulatory. These may or may not apply to the project. If they do, we need to understand their effect on our work.
These pertain to how ready the organization is to accept the final product. The bigger the change, the more issues there usually are. We need to know, for example, which stakeholders will be on board, which will resist the change, and what needs to be done to prepare the organization for the change.
We need to ensure that the business problem we’re solving and the proposed solution align with the organization’s goals and objectives.
These context questions are usually those about the current state.

Tip #3 – Know when to use open-ended, closed-ended, and leading questions

Open-ended questions allow the respondents to expand their thoughts. We ask open-ended questions any time we want to learn more. For example, we ask these questions when we’re just beginning an effort, during brainstorming, and when we need to get all the issues out on the table, etc.

Closed-ended questions are forced-choice questions. They have the answers embedded in the question itself, sometimes explicitly as in a survey question, or implicitly. I like to ask closed-ended questions when stakeholders are all over the board and we need them to focus. For example, given all these issues we’ve identified, if you had to choose 10, which would they be?

Leading questions are not questions at all. They sound like questions, but they’re really our opinions stated in the form of a question. “This is a pretty cool feature, isn’t it?” My least favorite leading question is one we often hear: “Have you ever thought about…solution.” Again, it’s not a question. It’s us presenting our opinion rather than asking what our stakeholders think. What’s wrong with that? Remember we’re in the middle of elicitation, which is about learning. Presenting our solutions during elicitation cuts off exploration because we’re telling rather than learning. Later, after we’ve completed elicitation and analysis, whether it’s for the whole project or a smaller part, we can make a thoughtful recommendation.

To summarize, effective elicitation is critical to the development of a final product that our stakeholders are happy with. Elicitation is not easy. There are several pitfalls which are difficult to overcome. But if we follow the tips provided in this article, we will deliver a product that our stakeholders actually like and want to use.

[i] I use the terms solution, final product, and end product synonymously. It’s the solution to the business problem we’re solving. It’s also the product or product increment being produced at the end of the project, project phase, or iteration.

5 Reasons KeyedIn is the PPM Software of Choice for Strategic PMOs

Written by Brad Egeland on August 24, 2021. Posted in Articles.

KeyedIn is an established PPM software provider that is designed to help PMOs get to the next level of PPM maturity. They do this through software products combined with services offerings that configure to user needs. Rich in functionality in all the critical PPM components – portfolio management, resource planning, project management, dashboards and analytics, and financial management – KeyedIn provides a number of other value-adds that give their customers an edge.

Powerful but affordable – KeyedIn is not beholden to a private equity firm that demands growth at the expense of service and sensible pricing. KeyedIn offers the power of a high-priced PPM tool without the high price tag.
Software that actually gets adopted – KeyedIn features an easy-to-use interface that drives adoption. Customers like Walgreens-Boots – currently with more than 2,000 users – have consistently cited the solution’s ease of use as a significant benefit.
Professional services and customer support that creates a lasting partnership – The KeyedIn services and support team is among the best in the industry. Even industry analyst Gartner, in a recent PPM Magic Quadrant report, acknowledged that “customers give [KeyedIn] high marks for its high levels of personalized customer service and support.”
Our vision for Agile Portfolio Management – With the rate of change in business only increasing, KeyedIn pioneered the concept of Agile Portfolio Management, which takes the Agile principles that have improved project execution and applies them to the top-down assessment of portfolio investments.
Integrations – As a best-of-breed vendor, KeyedIn understands the need to play nicely with the software and services an organization already has in place – from Agile development tools like Jira to ITSM systems such as Cherwell.

Some product screenshots examples:

Dashboards

Highly configurable, interactive dashboards to answer the questions most relevant to the user.

2. Resource Plan

Analyze resource allocation, availability, utilization, and capacity by department, team, role, project, skill, and availability. Assign resources to work with simple drag-and-drop.

3. Plan and Manage Projects

Central repository for all project, program, and portfolio information. Fully configurable layout. Content can be personalized to each persona/role and individual.

4. Task Planning, Kanban

Configurable Task Kanban Board allows users to visualize and manage tasks within an agile environment. Drag-and-drop tasks between board columns. Support for agile elements including Tasks, Stories, Features, etc.

5. Risk and Issue Management

Ready to try KeyedIn?

Are you ready to check out KeyedIn for yourself? Download your free trial today!

Tag: Requirements