Tag Archive for: project management

 

Adopting MBSE

This blog contains excerpts from a whitepaper titled, The Comprehensive Guide to Successfully Adopting MBSE, written by Lou Wheatcraft. 

Adopting MBSE: Challenging the Status Quo in Product Development

For product development teams to successfully implement a practice such as model-based systems engineering (MBSE), it requires the willingness of an organization to perhaps change processes and even tooling. Often, companies choose to stay with the status quo, but at what cost? Here’s a look at how adopting MBSE might help your teams, and the cost of not adopting MBSE. 

Understand the Need to Move for Change 

What is the Risk of Staying with the Status Quo? 

For the MBSE Implementation Project Team to be successful, management must recognize the need to change. How can management be convinced? Three words – RETURN ON INVESTMENT (ROI)!  

Think about these questions: 

  •  What has been the impact of the current, poorly executed product development efforts? 
  • What is the overhead associated with the current document-based approach?  
  • What are the current quality issues facing the organization that is catering it to profits: Failures, recalls, returns, warranty costs, lawsuits, negative reviews on social media, decreasing market share?  

The ROI argument usually works with management especially when they can be convinced that by investing in a data-centric practice of SE tailored to the organization’s needs, the overall product development process, product quality, time to market, and profitability can be improved as discussed previously. 

What is the ROI of Adopting MBSE? 

To entice anyone — especially an entire organization — to make a change, proving ROI on the resource investment is key. Here are some key points to consider: 

  • The more effective the Systems Engineer (SE) processes, the less rework and fewer cost and schedule overruns.  
  • By moving to a data-centric practice of SE, the probability of achieving a competitive advantage can be improved by removing obstacles to being able to deliver products on time, on budget, and that meet or exceed customer and quality expectations. 
  • From a cultural perspective, the personnel responsible for product development and will be most affected by the change must be shown, and how the change will benefit them.  

Visit our interactive content page for ROI Calculators and more! 

Combating Opposition to Change

A good process is not one that is something people have to do in addition to their job, rather it is one that helps people do their job more effectively. – LOU WHEATCRAFT

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

Get Team Buy-In

To get buy in from the product development teams, the MBSE Implementation Project Team must: 

  • Understand what problems the product development teams are having and show them how moving to a more data-centric practice of SE will address those problems and make their job easier than the current document-centric approach. If the change results in more work or makes communication harder, the battle will be lost. For example, the lead engineer or project manager may already be over their head and working 50–60-hour weeks. Requiring them to learn how to use a new tool or set of tools and implement a new process may be too much of a load for them to bear! However, if they are provided with a dedicated person that has the training, knowledge, and experience in the new processes and tools to help implement the changes and train other team members, they will be much more receptive. They will also be much more receptive if this results in them having to work fewer hours and having fewer crises to deal with each day! 
  • Be convinced of the utility of the changes, how the changes result in a better product and result in less rework for them. Frequently the reason project team members are working long hours is because they are always fighting fires, going from one crisis to another, which resulted from the lack of the proper SE tools, processes, data, and information in the first place! The culture needs to be changed from one of firefighting to one of fire prevention. As time passes, they will become advocates for the changes that have been made and welcome further change. 

The MBSE Implementation Project Team’s mission statement will be something like: “Improve our product development processes by adopting MBSE within the organization by moving from a document-centric to a data-centric practice of systems engineering.” Along with this mission statement, they will need to define a set of specific goals and objectives along with measures of success. Once defined, they will need to get agreement from management on these goals, objectives, and measures. 

RELATED POST: Systems Engineers Career Path – How to Elevate

Get Management Buy-In 

Project success is dependent on having a high-level, C-suite project champion and getting management buy in. A major challenge for the project will be convincing management and other key stakeholders that it is time for adopting MBSE and moving from a document-centric to a data-centric practice of SE and knocking down the walls of resistance. Some common reasons for them not wanting to move to a data-centric practice of SE include: 

  • “We have been doing product development using our current processes for years, why should we change?” 
  • “Implementing SE from a data-centric perspective may work for others, but not for us.” 
  • “This all seems very complicated, we don’t have the knowledge, experience, or tools.” 
  • “Our current SE work products, like requirements, are managed in an RMT. FFBDs, and other diagrams we are currently using are models, so aren’t we already adopting MBSE?” 
  • “It is too expensive to procure the needed SE toolset, maintain the tools, and train our people to use those tools.” 
  • “We don’t have the budget to incorporate SE from a data-centric perspective at this time.” 
  • “The expense and associated process to get new SE toolset installed on organizational computers is too great.” 
  • “We would have to make signification IT infrastructure upgrades to accommodate the additional volume of data and performance requirements of the new SE tools.” 
  • “We deal with the development of classified systems; controlling access and maintaining security will be too difficult.” 

Sound familiar? Often the pushback can be attributed to a lack of understanding the risks associated with the current state of the organization, understanding the benefits of moving toward a more data-centric practice of SE, and what level of SE capability is appropriate for the organization.

RELATED POST: Whitepaper: A Path to Model Based Engineering (MBSE) with Jama Connect

Adopting MBSE: The Road to Success 

To inspire a shift from a document-centric to a data-centric practice of SE in your organization, it’s vital to show both teams and management the value and expected ROI in doing so. Moving away from a current way of doing things isn’t always an easy road, but the risks of staying with the status quo are often great—and the rewards for changing processes and culture are often even greater.  

An organization will be successful in practicing SE from a data-centric perspective when it is considered to be the “gold standard” for system development within the organization. However, the road to success is long — it takes very strong, unwavering leadership and experience to get this done right. It is human nature to try to push back and say that it isn’t possible, but it is.   

This is Part 2 of a blog series covering a whitepaper titled,The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part I, Part III, and Part IV.

Adopting MBSE

What does it mean to practice SE from a data-centric perspective?

Successfully adopting MBSE and moving toward a data-centric practice of SE is much more than just acquiring and using a specific tool, set of tools, or focusing on the use of a specific type of model. As stated previously, MBSE is not just about the development of SysML or other language-based models nor just practicing model-based design. MBSE is itself made up of puzzle pieces, all of which contribute to the successful adoption of MBSE. To be successful, the following ten areas of capability associated with data-centricity must be addressed.

01: Holistic Product Development

A key tenet of data-centricity is taking a holistic view of product development and managing data and information within an integrated/federated environment. The focus is on multidiscipline, collaborative, project teams (e.g., integrated product teams). Many organizations still operate in organizational silos, with team members’ loyalty toward their specific silo rather than to the project team. When issues occur, the tendency is to blame those in other silos. Each silo often has its own processes, specific toolsets, data, and artifacts. Often the data and information are generated independently from those in other silos and are not in a form to enable sharing. This can result in inconsistencies, correctness, completeness, and currency issues of the data maintained in these artifacts. When moving toward data-centricity, organizations must have a holistic view of product development, minimizing the silos, encouraging collaboration, and improving communications not only between team members but between different tools used to generate and maintain data and information. Rather than treating Systems Engineering separate from Project Management (PM), projects must integrate both sets of functions such that there is a single project team that does both functions.

02: Manage Product Development Across the Lifecycle

Rather than having tools that are specific to a given organizational silo, a key characteristic of data centricity it that related data and information that represents lifecycle activities and associated artifacts can be linked resulting in “digital threads” that link related information together across the product lifecycle. This linkage enables project team members to work collaboratively and establish traceability between needs, design input requirements, system analysis artifacts, diagrams, models, architecture, design, system verification artifacts, and system validation artifacts. Traceability aids in change impact assessment across the product lifecycle helping ensure completeness, correctness, consistency, and currency of the data and information and resulting artifacts.

03: Enterprise Level Data and Governance Policy, Processes, & Procedures

Because of the dependence of not just the project teams, but the overall organization on electronic forms of data and information and increasing threats associated with the security of this data and information; enterprise-level policies, processes, and procedures concerning data governance and information management must be defined, implemented, and enforced.

04: Project Level Data and Information Management

Within the context of the enterprise-level data governance and information policies, each project must include their specific implementation of these policies within their Project Management Plan (PMP) and Systems Engineering Management Plan (SEMP). Because of the importance of managing the project’s data and information, the project is encouraged to develop and enforce a project-level Information Management Plan (IMP). Other supporting plans (e.g., requirements management plan) need to comply with the data management policies within the higher-level plans for both the project and enterprise.

RELATED POST: The Real Intent of Model-Based Systems Engineering

05: Master Ontology

Terminology and language are key to successful communications not only between team members but between tools. For a given enterprise, an enterprise-level ontology (data dictionary and glossary) must be developed to clearly define specific terminology and relationships of various terms used within the organization and the project. This is critical when there are product lines, multiple project teams, and the need to share data and information between current projects as well as reuse data and information for future projects. Within the enterprise-level ontology, individual project teams can define their project-specific ontology consistent with the enterprise-level ontology.

06: Master Schema

Here the word “schema” is used to describe how the data and information are organized and managed within individual tools and associated databases. It includes the naming of individual data and information items, defining relationships between data items, and the import and export of data and information. From both an enterprise and project perspective it is important to define a master schema that the SE and PM tools within their toolset are compliant in order to enable data integration, shareability, and reuse.

07: Use of Attributes and Associated Measures

Data centricity enables the project to define and use attributes that can be used to manage project activities across all system life cycle stages. For needs and requirements, attributes can include rationale, priority, criticality, source, owner, traceability, risk, maturity of needs definition, needs and requirements definition status, design implementation, system verification, and system validation. Attributes can be defined to aid in reusability and product line management. Attributes can also be associated with key measures defined by stakeholders within their goals and objectives. These measures include key performance indicators (KPI), measures of suitability (MOS), measures of effectiveness (MOE), measures of performance (MOP), key performance measures KPP), technical performance measures (TPM), and leading indicators (LI). Data representing these measures and attributes can be used within the SE and PM tools to generate reports, dashboards, etc. which are used to better manage the project and system engineering processes providing managers near real-time status information and enabling them to identify and correct possible issues before they become problems.

08: Configuration Management

Adopting data-centricity, the project’s artifacts and underlying data and information are developed, analyzed, and managed holistically within the data and information model. Because the data and information are managed within the project’s data and information model, this model represents a single source of truth (SSoT) for the project. Rather than configuration control of each individual artifact represented by the data and information in the model, the project team can configuration control the model which represents the baseline state of the artifacts represented by the data and information in the model at any given time. “Visualizations” of the data and information in the form of the various artifacts represent the baseline version of that artifact. Even when these visualizations are extracted as reports, the SSoT is still the data and information model from which they were generated.

Note: for many organizations, this is often their biggest challenge in that it requires the organization to redefine its concept of configuration management. However, as stated previously, configuration management of individual artifacts requires significant overhead in both cost and time to individually configuration manage individual documents as compared to managing the data and information model that is representative of moving towards a data-centric practice of SE and PM.

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

09: Systems Engineering (SE) Tool Set

Data centricity requires projects to move beyond the use of common office applications: word processing, spreadsheets, presentations, basic drawing and diagraming tools, and requirement only management tools to define, analyze, record, and manage needs and requirements and other SE artifacts. Rather, projects must transform their SE process such that SE artifacts are developed using SE tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the SE tools within the project’s toolset as well as shareable with the project’s PM tools. When selecting specific SE tools to be included in the project’s toolset, it is important that the project determine the types of information and methods of analysis that are needed based on their specific product line, culture, and workforce.

10: Project Management (PM) Tool Set

Data centricity also requires projects to move beyond the use of common office applications for project management e.g., budgeting, scheduling, cost management, risk management). Rather, projects must transform their PM process such that most of the PM artifacts are being developed using PM tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the PM tools within the project’s toolset as well as shareable with the project’s SE tools. For example, Work Breakdown Structures (WBS) can be linked to Product Breakdown Structures (PBS) and physical architectures to enable management of budgets, schedules, resources, and risks associated with each system and system element within the product physical architecture.

Visit these links for the rest of this series: Part I, Part III, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE


This is Part I of a blog series covering a whitepaper titled, The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part II, Part III, and Part IV.

Introduction 

In a previous paper, we discussed key questions concerning Model-based Systems Engineering (MBSE) including what MBSE is, its true intent, why organizations should adopt MBSE, and the benefits. If you haven’t read that paper, it’s worth taking a look. 

We made the point that the goal of an organization when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed — along with a model of all the system life cycle process activities, resulting in artifacts, and their underlying data and information. 

This paper will go into more detail as to key factors associated with successfully adopting MBSE, what it means to practice SE from a data-centric perspective, and provide a methodology to define a road map tailored to your organization resulting in the successful adoption of MBSE. 

RELATED POST: The Real Intent of Model-Based Systems Engineering

Key factors associated with successfully adopting MBSE 

Sadly, the attempts of many organizations to successfully adopt MBSE often end in failure. The process of adopting innovative technology like MBSE and moving toward a data-centric practice of SE can be considered to be a project in its own right. There have been numerous studies and reports concerning factors of why projects fail, and factors associated with projects that succeed. When adopting MBSE, these factors must be considered. Organizations that are able to successfully adopt MBSE and move to a data-centric practice of SE address the following key factors: 

01 – Getting Corporate Level Management Buy-In and Support – Success Starts at the Top! 

In an earlier paper, we discussed issues associated with a document-centric approach to product development of today’s increasingly complex, software-centric products along with the benefits of adopting MBSE from a data-centric perspective to address these issues. There must be a project champion that can clearly communicate these issues and benefits at the corporate level in order to get buy-in across the organization. 

A key consideration when getting this buy-in is how these issues and benefits are communicated. The adage “know your audience” is important. A common mistake when approaching higher-level management is using terminology that does not address their needs in a language they understand. When getting buy-in concerning the company adopting MBSE, you must clearly communicate to them what MBSE is and how the organization will benefit in terms of outcomes they can relate to. Giving them a demonstration of a specific tool using a lot of technical jargon can result in them quickly losing interest. They are interested intangible outcomes of a proposed solution that addresses business-related issues (problems): less overhead, decreased time to market, higher quality, decreases in post-launch issues, fewer issues associated with a product being approved for use, increased profits, rising stock prices, and a growing company. They want to understand how adopting MBSE will result in these types of outcomes. 

02 – Forming a Dedicated Project Team 

Rather than leaving it up to individual project teams to each attempt to adopt MBSE, a corporate level dedicated MBSE Implementation Project Team (IPT) is needed. For smaller organizations and startups this IPT might be a single person. MBSE is just one puzzle piece in the larger set of organizational puzzle pieces. To be successful, the larger, integrated puzzle must be considered to ensure the MBSE puzzle piece will fit. Other puzzle pieces include data governance policies, information management plan procedures and work instructions, information technology (IT) infrastructure (networks, internet, clouds, applications, computing devices, etc.), the product line, product development processes, procurement processes, company culture, workforce, etc. A dedicated project team can deal with possible issues in all these areas from a corporate, holistic perspective across organizational silos enabling a successful adoption of MBSE, helping to ensure the MBSE puzzle piece can be integrated within the overall corporate puzzle. 

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

03 – Involving Key Stakeholders 

The various stakeholders involved in adopting MBSE must be included. These stakeholders must not only include the users, but other stakeholders that will be affected by the adoption of MBSE including those that will benefit, those involved in the activities required to adopt MBSE, and those from enabling and supporting organizations. Referring back to the puzzle analogy, stakeholders must be included that represent each of the above-listed puzzle pieces. Each stakeholder has expectations that must be addressed by the project team along with key drivers and constraints a successful project must consider in order to achieve a successful outcome. 

04 – Defining The Problem, Opportunity, Outcomes, Needs, and Requirements at the Beginning of the Project 

The project team and stakeholders at all levels of the organization must be aligned to a common understanding of the problem/opportunity that is driving the adoption of MBSE, to a common mission statement, goals, objectives, clear outcomes, needs, and requirements. Like any other project, these must be defined and agreed to from the beginning so that there is a clear roadmap to success and well-defined outcomes against which success can be measured. 

05 – Understanding the “Goldilocks Principle” 

The Goldilocks principle is about doing what is “just right” – not too little, not too much. When adopting MBSE and moving towards a data-centric practice of SE, the project team must understand the needs of the organization, what it means to practice SE from a data-centric perspective, and develop a practical and feasible roadmap. Delivering an MBSE capability that is too little can result in stakeholder expectations not being met, disappointment, and a failure of project teams to successfully adopt MBSE. Going overboard and implementing more than is needed can be overwhelming, turning people off to the concept and again a failure of project teams to adopt MBSE. 

This last point is especially important. “Just right” must be defined from a user perspective. The users are the product development project team members who will be conducting their project based on the processes and tools provided that will enable them to adopt MBSE for their project and move to developing their products from a data-centric perspective. They have expectations concerning being able to be more productive and effective. Meaning the processes and tools provided should not be viewed as things they have to do and use in addition to their job – resulting in more work; rather processes and tools they can follow and use that are an integral part of how they do their job – resulting in less work, a higher quality product with a shorter time to market. The new processes and tools enable them to deliver winning products: those that meet the needs of their customers, within budget and schedule, with the required quality. 

From a user perspective the following attributes must be addressed within the processes defined and tools selected for use: 

  • Full functionality; does what is needed, nor more, no less
  • Intuitive; easy to learn and use
  • Easy and fast to implement
  • Enable collaboration between team members, no matter their geolocation
  • Enable traceability of data, information, and artifacts across the system lifecycle
  • Enable change impact assessment across the system lifecycle
  • Reduces the time to define and manage needs and requirements
  • Supports verification and validation planning and execution
  • Tailorable to the organization’s product line, work instructions, and workflow
  • Helps ensure compliance with standards and regulations
  • Helps manage risk across the lifecycle
  • Enables management to track project status across the lifecycle 

Visit these links for the rest of this series: Part II, Part III, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE


Requirements Management Plan 

Product success depends upon the successful project management of the product’s requirements. Effective requirements management, in turn, requires thoughtful planning. 

 A requirements management plan describes how you will gather, analyze, document and manage the requirements of the project. It should describe how you intend to gather the high-level project and product requirements from project stakeholders, industry standards and governmental regulations, as well as the more detailed product requirements you will collect and develop over the project lifecycle. Your requirements management plan should also specify how you will manage changes to requirements after they have been approved. 

Your requirements management plan is a tool for communication. It provides all your project’s stakeholders with a common understanding of how the product’s requirements will be managed to ensure success. 

In this article, we’ll describe the requirements management planning and the recommended components of a requirements management plan. 

What is Requirements Management Planning 

Requirements Management Planning is the process of documenting how you will gather, analyze, document and manage the requirements of a project, manage changes to requirements once they have been approved, manage the configuration of the requirements documentation, and track verification of the project’s requirements. 

Components of a requirements management plan 

A solid requirements management plan will be composed of several components. Here, we’ll describe our recommended sections. Depending upon your industry and organization, not all of these sections may be applicable to your situation. 

Project overview 

Briefly describe the purpose of the project. Explain the need the product will fill for the customer or target market and how its development will benefit your company. Mention important goals for the project and any notable constraints that may have been imposed upon it.  

Roles and responsibilities 

This section lists the roles of those who will be involved with managing the requirements through the rest of the project lifecycle, along with the responsibilities of each role. 

Typical roles include: 

  • Project manager 
  • Lead analyst / lead requirements engineer 
  • Analyst / requirements engineer 
  • Stakeholder 

The project manager typically has overall responsibility for managing the scope of the requirements for the project.  

The lead analyst / lead requirements engineer may also be a lead systems engineer or lead developer. This role is generally given overall responsibility for requirements development and integrity.  

Analysts and requirements engineers assist the lead analyst / lead requirements engineer and are typically tasked with following the specified procedures for managing the subset of the project’s requirements for which they have been given responsibility. 

Other project stakeholders who provide input to the requirements base are generally given responsibility for reviewing the requirements at specified milestones. 

Tools 

In this section of your plan, describe any automated tools that will be used to manage the requirements. Provide a brief overview of how those tools will be used during the requirements management process, and reference any documented procedures governing the use of the tools.  

More detailed descriptions of how the tools shall be used in the various steps of the process should be provided in the sections of the plan that describe those steps. 

Requirements gathering 

Describe the process that you will use to elicit, analyze and document the requirements. Then, describe the requirements gathering techniques you will use and with what groups you will use them. 

RELATED POST: 11 Requirements Gathering Techniques for Agile Product Teams

Categorization and assignment 

Here, you will describe your process and procedures for dealing with various types of requirements. 

Describe how requirements will be categorized within your requirements management system. Typical categories include:  

  • Functional 
  • Non-functional 
  • Internal 
  • External 
  • Regulatory 
  • Performance 
  • Quality 
  • Training 
  • Support 
  • Maintenance 

 The difference between functional and non-functional requirements—what the product must do versus any constraints on how the product must be constructed—normally impacts how the requirement will be verified. For more information on non-functional requirements and their impact on product development, click here. 

Internal requirements will generally be driven by the needs of stakeholders within your organization. External requirements will include those driven by customers, market forces, government regulations industry standards, etc. 

A requirement’s category will dictate, in part, how it is assigned for development, implementation and verification. Your plan should describe your policies and procedures for assigning requirements to subsystems or components or by work breakdown structure (WBS). 

Prioritization 

Companies will prioritize the fulfillment of some requirements over others. Reasons for high prioritization may include market demand, regulatory compliance, contractual obligation, or internal stakeholder need. 

That’s why it’s important to plan and document how you will prioritize requirements for development and release. Keep in mind that you will likely describe in detail your rules for prioritizing requirements in your Product Requirements Document. 

Traceability 

Describe your overall process for tracing requirements throughout the product lifecycle: from gathering, through decomposition, development, implementation and verification. Mention the tools to be used to accomplish the traceability process. 

Requirements and their attributes need to be tracked throughout the project lifecycle to ensure fulfillment. Attributes to be tracked may include: 

  • Name
  • Type 
  • Project unique identifier 
  • Source (stakeholder, document, parent requirement, etc.) 
  • Children (lower level requirements derived from the requirement) 
  • Assigned element of the WBS where it will be addressed 
  • Verification method (if your project requires a variety of methods) 
  • Verification reference (to the procedure that will verify the requirement) 
  • Compliance reference (applicable regulations/paragraphs) 

RELATED POST: What Is Requirements Traceability and Why Does It Matter for Product Teams

Change management 

As a project evolves, requirements will need to be added or modified. Therefore, your requirements management plan should include a section that describes your policies and procedures for change control. 

Change management (or change control) generally involves documenting each proposed requirements change in a change request. Once written, the change request is analyzed by affected stakeholders for any possible impact on project objectives or other requirements. The change request then goes before a change control board where it is either accepted (to be implemented) or rejected (and either revised or dropped). Your procedures for change control (raising, reviewing, tracking and approving change requests) should be described or referenced in this section. 

Configuration management 

Describe how you will monitor and control changes to your requirements documentation. Configuration management deals primarily with how documents will be revised and released during a project. 

For many projects, depending upon your organization, this section may be combined with the Change Management section just described. For very large projects, you may want a separate Configuration Management section. If you have a separate Configuration Management Plan you’ll probably want to reference it and keep this section brief. 

Verification 

Finally, describe the methods and metrics you will use to verify requirements. Specify how their achievement will be measured, tested, etc.  

If you use a variety of verification methods to verify different types of requirements, you will likely want to give a brief explanation of the procedures for each and how each type of verification is documented.  

Benefits of requirements management planning 

As mentioned earlier, your requirements management plan is a tool for communication. It helps your analysts, systems engineers and developers get up to speed and stay on the same page when it comes to managing your project’s requirements. Plus, it gives higher-level stakeholders a warm, fuzzy feeling that your product’s requirements will be properly managed to ensure your product’s success. 

For more in-depth information… 

Requirements management and requirements management planning can be greatly simplified through the use of a state-of-the-art requirements management tool like Jama Connect. For a deeper dive, visit our Essential Guide to Requirements Management! 

requirements-management-hub


Top-Signs-Your-Design-Review-Process-is-Hurting-Your-Business

Design review processes and their impact on product development.

Development organizations typically have a predefined set of formal design reviews that are held throughout the development process. A design review usually includes assessing design input requirements for adequacy, assessing the adequacy of a design to fulfill design input requirements, and verification/validation-related reviews. When done correctly, design reviews are an important part of a robust product development process because they help identify design issues early when they cost less to fix.  When not done correctly, design reviews can be detrimental to the success of a development organization. So what are the top signs that design reviews are hurting your business and not helping you develop better products on time and within budget? 

  1. Not planning design reviews appropriately. 
  2. Performing design reviews that are not effective or efficient. 
  3. Not following up on review action items. 

RELATED POST: Five Key Design Control Practices that Improve Compliance and Help Develop Better Products

Not planning appropriately for design reviews involves not performing design reviews at the correct time and not sending out review material with sufficient time that reviewers can adequately prepare for the review. Often, formal reviews involve reviewing deliverables associated with a milestone or a certain phase of the development process. Because these reviews are required by procedure, they are generally performed but often end up as a status marker of where the project is at, instead of a design review intended to identify issues. Additionally, design reviews can be performed at any time in the development process, when a review of some element of the design is beneficial in identifying potential issues. These technical reviews can be invaluable in identifying design issues early in development and should be performed on an as necessary basis. Development organizations are sometimes hesitant to hold additional reviews, other than the required formal reviews, because of the time required to prepare, perform, and document the review, thus passing up opportunities to improve the design while it is still less expensive to make changes.   

Unfortunately, oftentimes, design reviews are just performed to meet the regulatory requirement, but not with the goal of identifying issues. The check-the-box mentality, prioritizes project schedule over product quality, as it passes upon opportunities to significantly impact and improve on the quality of the design before the design is frozen. In order for design reviews to be efficient and effective: 

  • Reviewers should be provided sufficient time to review the material prior to the review meetings. 
  • An independent reviewer, a person with no responsibility for the design being reviewed, should be invited to the review.  
  • All participants should come prepared for the review, having reviewed the material beforehand. 
  • An experienced facilitator/moderator shall be utilized, the role of the facilitator is to keep the meeting on track, ensure the agenda is followed.  
  • Utilize a scribe to record the meeting minutes, this will free the design owner to fully focus and participate in the review.  It will also allow the meeting to progress more efficiently. 
  • Ideally, utilize a requirements tool, like Jama Software, to automate and centralize the above activities. 

RELATED POST: A Guide to Requirements Elicitation for Product Teams

Gathering metrics on the number of issues found during reviews, the types of issues found, and the amount of time spent in reviews can help determine the effectiveness of your design review process.   

When a review is performed appropriate documentation should be generated. First, a design review agenda should be prepared to detail the date and time of the review, the location of the review, the review objective, the review participants and their roles along with the materials to be reviewed. During the review, the list of attendees should be documented, along with items discussed, decisions agreed to, conclusions reached and any action items generated, along with the person responsible and due date of the action items. Review minutes should be published containing all this information.   

When action items are generated as a result of a design review, a requirements tool, like Jama Software, should be used to track review action items to completion. Ideally, action items should be completed prior to the next project milestone or major review. Not following through on review action items is not only a regulatory liability but can give the impression to reviewers that the time spent in reviews is wasteful, causing them to treat design reviews as a check-the-box activity. 

In summary, design reviews can be a very helpful tool in identifying design issues early, when they are less costly to fix. However, in order for design reviews to be helpful, they need to be planned and held at the appropriate times during the development process, following guidelines for effective design reviews, documenting design reviews appropriately, and following up and tracking design review action items to completion. If you are going to spend the time in design review, let the time be well spent, let reviews serve their purpose, and gain the benefits from the time and resource investment in this activity. 


managing project scopeA project manager is tasked with keeping everything running smoothly, from project launch to completion. Scope creep, which happens when stakeholders unexpectedly change requirements and demands, occurs in about 52% of projects, and the consequences can be serious.

Imagine that a customer is hiring a package solution vendor to migrate data into a new package. Halfway through the project, the customer decides to add six additional data conversions to the workload. The customer believes the workload is within the original scope, but the vendor disagrees. This miscommunication leads to frustration, lost time and, ultimately, the project’s cancellation.

Scenarios like these can be avoided when you reexamine how you handle project scope management and make changes that improve communication and processes. Stakeholders will have a clear understanding of what tasks are in scope, and when something comes up that is out of scope, everyone will have a road map of how to move forward.

What is project scope?

A project has both a product scope and a project scope. The concepts sound similar, but there are major differences. Features and functionality are the main focus of the product scope. The work that needs to be completed to deliver on the product scope is the focus of the project scope.

Product scope: features and functionality of the product

Imagine a project that is focused on building a new software application. The product scope is to create a new workflow application that meets the requirements of the internal and external stakeholders. Project scope management will ensure the work gets done accurately, on time and without potential miscommunication.

What is scope creep?

Projects can get bloated with extra tasks that weren’t included in the initial discussions. Project scope management clearly defines what is and what is not included in the project.

A natural control mechanism is created that helps if a client decides to add tasks to the project that weren’t included upfront. Customers won’t always understand why the work isn’t in scope if you can’t refer them to the initial approved document.

For example, a customer might decide they want to include an online tutorial to help users with a new learning system. This expands the scope of the project and adds more work for your team. Investing time in project scope management will protect you from scope creep and make sure your team gets paid more if work is added to the project.

How are project scope and project requirements different?

The project scope defines the specific work that needs to be completed. Project requirements are focused on the specific items that should or should not be included in the project. What does the user want from the product? The answer to this question will shape the project requirements.

A carpenter requires the ability to drill holes that are two inches deep. Accomplishing this requires the carpenter to have a drill bit that is capable of drilling two-inch-long holes.

The scoping of the project is focused on the materials and processes that go into creating the drill bit that is able to drill a two-inch-deep hole. Typically, requirements are scoped during each phase of a project rollout.

RELATED POST: Requirements Management Tools and Software

What is involved in project scope management?

A project scope management plan will help you proactively avoid scope creep and ensure that your customer receives the outcome they expect. This process includes involving key stakeholders in the conversation early to get a clear definition of the project and what is and isn’t included. There are several important aspects of scope management, which include:

  • Kick off the scope management process. Who are the key stakeholders for the project? Define these stakeholders upfront, and set expectations for what to expect and what will be required of the client.
  • Define the necessary requirements. This is an information-gathering stage. Hold interviews with stakeholders, take surveys and begin a deep dive into what’s required to make the project a success in the eyes of the customer.
  • Create a project scope statement. With research in hand, you can now define project scope. This definition is important because it’s the backbone of all upcoming project activities and will serve as a guide during the project. A project manager should be able to look at it and determine what is included in a scope. For example, if an additional request comes up, the project manager can ask “What is the project scope?” and “Does this task fit into that scope?”
  • Seek approval of the scope of a project. It’s critical to have the customer’s formal approval of the project scope. If scope creep happens in the future, you can redirect the client to the agreement and figure out the best way forward.
  • Define the work breakdown structure (WBS). Everyone knows that if you’re completing a large project, you need to break it down into small pieces. The WBS is where this happens. You are clearly defining the deliverables at each turn in the project.
  • Validate the project scope. A project manager needs to continually check to ensure the scope of the project is being controlled. This may include matching performance reports to project requirements to identify any potential gaps. And if changes are required, it could include going back to the initial agreement to determine if those fit within the scope of project or a change order is required. Ultimately, the goal is to ensure that the deliverable is completed on time and within budget.

Most people have heard the expression “measure twice, cut once,” and that’s what you’re doing during project scope management. The project scope management process is time-consuming, but investing at this stage of the project has the potential to save you time, money and frustration in the future. Everyone understands what work is required upfront, and they can easily stay focused on the final delivery.

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference? 

Accommodating increases in scope

There will be times when the customer wants to add work. The scope will make it clear the work is outside the original agreement, but you can still accommodate those requests with a few strategies:

  • Define functions with lower priority or less time sensitivity than were planned for the current release in order to create room for scope additions.
  • Bring on more development staff to handle the additional tasks and reach your target launch date.
  • Outsource some of the work to meet the client’s deadline.
  • Extend the schedule for the current release to accommodate the requested additions to the project functionality.

If you’ve done a thorough job during project scope management, it will be clear that the client will need to pay more to accommodate the request. But you can still keep the customer happy by staying agile to meet their deadline or making other accommodations.

Avoiding common scope management pitfalls

If you want to improve project scope management, it helps to understand common pitfalls. There are mistakes that many companies make that transform happy customers into frustrated and confused customers. Consider these common pitfalls when creating scope management documentation:

  • Work that is not clearly defined. Ambiguity is not your friend in the area of scope management. A lack of clarity opens the door to confusion and the prospect of completing unnecessary work. Clearly define the scope and leave no room for misinterpretation.
  • An incomplete scope. The scope should include all critical elements of a project. No area is too small to include, because if the scope is incomplete, the potential cost is high.
  • A lack of collaboration. Stakeholders are a critical part of scope management because they are the ones who clearly define project requirements. Make sure that no key stakeholders are left out of the process or, worse, added later, when the project scope has already been defined.
  • A lack of formal approval of the scope. All stakeholders need to formally approve the project scope. Receiving buy-in keeps you on track and helps you anticipate potential challenges before you’re underwater in project tasks.

Understanding potential pitfalls upfront will assist with successfully navigating the scope management process. But it’s also important to periodically evaluate your technology tools and ask whether there are tools available that could help you manage projects more effectively. Many technologies can help you streamline projects and gain greater efficiency.

Tools and software that help manage project scope

Technologies and tools can help you build complex products, systems and software to improve cycle times, increase quality, reduce work and mitigate efforts in proving compliance. A requirements management software program can be leveraged to help software teams include test and risk management capabilities, enabling teams to scale their product development.

Jama Connect helps you deliver high-quality products on time and on budget by aligning stakeholders through efficiency and collaborative reviews; identifying risk early; and visualizing connections between regulations, requirements and test cases through the development process.

See how Jama Software helps product teams define and manage scope by downloading our solution overview.


Defining Project Scope

Every product development team talks about project scope and team members often complain about unending scope creep. The vision and scope document (often including a use case diagram and a context diagram), otherwise known as the MRD (marketing requirements document) or business case, is a key deliverable in defending against scope creep. You don’t necessarily need a standalone vision and scope document for a small project. Any project of any size, though, will benefit from such strategic guidance, even if it’s just a paragraph or two at the beginning of the requirements specification. 

Vision and Project Scope

defining project and use case diagrams-1

Both the vision and the scope are components of the project’s business requirements. I think in terms of the product vision and the project scope. I define the product vision as: “A long-term strategic concept of the ultimate purpose and form of a new system.” The product vision could also describe the product’s positioning among its competition and in its market or operating environment. 

A well-defined scope sets expectations among the project stakeholders. It identifies the external interfaces between the system and the rest of the world. The scope definition helps the project manager assess the resources needed to implement the project and make realistic commitments. The scope statement defines the boundary of the project manager’s responsibilities. 

Your scope definition also should include a list of specific limitations or exclusions—what’s out. Obviously, you can’t list everything that’s out of scope because that would include every detail in the universe except for the tiny sliver that is in scope for your project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project, but which are not included. I know of a project to build a Web site for a national sports team that included the following exclusions for the initial release: 

  • There will be no virtual or fantasy games via the Web. 
  • There will be no ticketing facilities on the site. 
  • There will be no betting facilities available. 
  • The demographic details for newsletters will not be collected. 
  • Message boards are out of scope for phase 1. 

Some stakeholders involved with this project might have expected these capabilities to be included. Itemizing them as exclusions makes it clear that they won’t be. This is a form of expectation management, an important contributor to project success. 

Related: Project Management Best Practices  

Context Diagram

The venerable context diagram dates from the structured analysis revolution of the 1970s. Despite its antiquity, the context diagram remains a useful way to depict the environment in which a software system exists. Figure 1 illustrates a partial context diagram for a hypothetical corporate cafeteria ordering system. The context diagram shows the name of the system or product of interest in a circle. The circumference of the circle represents the system boundary. Rectangles outside the circle represent external entities, also called terminators. External entities could be user classes, actors, organizations, other software systems to which this one connects, or hardware devices that interface to the system. 

The interfaces between the system and these external entities are shown with labeled arrows, called flows. If the “system” is strictly an electronic system involving software and perhaps hardware components, flows will represent data or control signals. However, if the “system” includes both a software application and manual operations, flows could also represent the movement of physical objects. Two-headed flows indicate update operations involving the data object on the flow. 

defining project and use case diagrams-2

The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals: no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable. 

Despite the limited view that the high level of abstraction imposes, the context diagram is a helpful representation of scope. It serves as a tool to help the project stakeholders communicate about what lies outside the system boundary. 

RELATED: High Cost of Poor Requirements Management

Use Case Diagram

Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows a partial use case diagram for our cafeteria ordering system. The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box represent actors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately (exactly, in this example) to the external entities shown in rectangles on the context diagram. 

defining project and use case diagrams-3

Unlike the context diagram, the use case diagram does provide some visibility into the system. Each oval inside the system boundary box represents a use case. The use case diagram shows the interactions of the system with its users and some connections between internal system operations, albeit at a high level of abstraction. 

The arrows on the use case diagram indicate which actors participate in each use case. In Figure 2, the arrow from the Patron to the oval labeled “Submit Feedback” means that the patron actor can initiate the Submit Feedback use case. The arrow from Submit Feedback to the Menu Manager actor indicates that the Menu Manager participates somehow in the execution of Submit Feedback. Arrows on the use case diagram do not indicate data flows as they do on the context diagram. In addition to showing these connections to external actors, a use case diagram could depict logical relationships and dependencies between use cases. 

RELATED: Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)

The use case diagram provides a richer scope representation than the context diagram because it provides a high-level look at the system’s capabilities, not just at its external interfaces. There is a practical limitation, though. Any sizable software system will have dozens of use cases, with many connections among them and between use cases and actors. Attempting to show all those objects inside a single system boundary box quickly becomes unwieldy. Therefore, the analyst needs to model groups of related use cases as packages or to create multiple use case diagrams. 

Many analysts have found the context diagram and use case diagram to be helpful ways to represent and communicate a shared understanding of a project’s scope. In Part 2 of this series, I’ll describe two other techniques for defining scope, feature levels and system events. 

Check out Part 2, Defining Project Scope: Feature Levels and System Events 

Check out Part 3, Defining Project Scope: Managing Scope Creep 

Download our eBook, Best Practices Guide for Requirements and Requirements Management, to learn the fundamentals of requirements and how effective requirements management can keep your projects on time and on budget.

READ THE EBOOK

This is an updated version of a 2014 article by Karl Wiegers. You can read the archived original here https://www.jamasoftware.com/blog/context-and-usecase-diagrams-defining-scope/.


There are three main aspects of a project that tend to be in regular tension with one another: quality, schedule, cost. Typically, project management is about managing the tension that arises as focus and prioritization shift between these three elements.

Many times, organizations are forced to decide between pushing schedules, reducing costs, spending more on resources, and maintaining quality throughout the life of a product’s development. As a part of a product development lifecycle, requirements play a very important role in attempting to reduce or at least mitigate the tension between these areas.

Know What You’re Developing, and Why

Quality is, of course, a highly significant aspect of any product development effort. For many organizations, quality is paramount — especially in the case of highly-regulated industries like medical devices or automobiles, where quality concerns essentially amount to safety risks.

To ensure quality, you need to know what you are developing and why. And then, what are the requirements that meet those needs? In other words, a product should be defined to a meaningful degree before development begins. The distinction and order of “why” and “how” before “what” is a key element of requirements management.

This certainly does not mean that the product must be fully defined and agreed upon before any development happens. However, there should be enough definition to demonstrate that stakeholders agree on the needs and the high-level requirements meeting those needs, including acceptance criteria.

This is where a single source system becomes crucial, allowing cross-functional visibility to facilitate feedback and reviews to reduce the time and work between definition and development.

Requirements and Quality Assurance

Requirements are used to define the qualities of a system, features, or subsystem that meet actual user needs. A dedicated requirements management platform, like Jama Connect, helps ensure that development activities trace to actual needs and builds confidence that those needs are being addressed through gap analysis.

A gap in coverage happens when a need has been identified, but the engineering response to that need has not been provided. We often see this when higher level requirements don’t relate to anything, such as when an epic might be lacking stories.

Another aspect of improving quality is getting the right people involved at the right time. More eyes can sometimes be a hindrance to speed, but having people show up late to a discussion is usually worse. It’s important to make sure that not only the correct people are involved, but that the process for collaboration and reviews is clearly defined and well supported with a purpose-built solution, like Jama Connect.

Lastly, a discussion about quality would be incomplete without verification and validation (V&V). When writing requirements, it’s important to remember that the ability for a requirement to be verified is a key quality of a good requirement.

Typically, verification will happen against each requirement and is established by acceptance criteria determined while defining requirements. Validation, on the other hand, is concerned with whether or not you built the right product.

Through verification, you may determine that the product or feature works, but validation is focused on answering whether you actually met the need you set out to fulfill.

When considering the decisions and trade-offs made around quality, especially in relation to cost and schedule, having verification and validation activities closely tied into requirements definition can bring quality discussions closer to the front-end of an effort and avoid impacts of finding issues late in the lifecycle. Having a live and actionable trace matrix is essential in supporting this, especially where a product’s quality is non-negotiable.

Staying on Schedule Requires Visibility and Tracking

Schedules are mostly concerned with timelines and meeting time-based delivery of the product or its features.

In order to manage a project, the approach needs to be determined and then the infrastructure put in place to support that approach. From a product definition standpoint, the requirements may need to be organized in a way that makes sense for decomposition and capturing the granularity needed to properly define and align the product and teams. From there, development teams will collect those requirements into backlogs of work and manage the development of activities using a preferred methodology.

A quick way to build efficiency into this process, regardless of the methodologies implemented, is to manage at the level of discrete, individual items and move away from documents.

In terms of releasing pressure on the schedule, the idea is that instead of gating development and work based on large documents, manage the state of individual requirements, moving them independently through definition, acceptance and into development. Of course, logical groupings of requirements will necessitate some structure, but just identifying that appropriate organization will minimize the collection size and improve speed.

An obvious detriment to the schedule is people working on the wrong things. This can happen when teams do not have visibility into how what they are working on connects to the larger product definition.

To avoid this, consider the trace to a defined need as part of the approval and criteria for adding requirements into the backlog. Working on requirements lacking this trace runs the risk of working on the wrong thing. Of course, as you get into development cycles, new work may be discovered that helps facilitate and enable development, but this should be considered as potential scope creep.

Lastly, when it comes to schedule, it’s important that teams are tracking their work. You’ll likely be asking different questions at different phases of the effort. The important thing is that you clearly identify what you need to track to ensure progress and minimize issues that might fall through the cracks.

Once you know what you need to track, then you need to capture that data. In Jama Connect, as an example, you can track the state of requirements across the workflow, from draft through approval, which helps determine progress and find roadblocks. At a minimum, you’ll want to consider tracking the status of testing as well. That information is not the only key to the schedule but is also very important when assessing quality.

Avoid Rework by Defining, Agreeing, and then Developing

From a project management standpoint, the key metric related to cost is typically actuals again budget, where we’d take a baseline of the estimated cost and compare it to the actual cost to date. However, the cost is about more than money spent against the budget. It is also concerned with the cost of missed opportunities or lost market share.

One of the most expensive occurrences in product development is rework. Rework happens when teams get through some development activities only to find that they didn’t build the right thing or that the user needs are not actually fulfilled by what was developed.

To avoid or at least reduce rework, teams must define, agree, and then develop. The more teams can align around what it is you’re actually building and just how that thing will be verified, the better-aligned development activities will be. Additionally, as requirements are generated, verification should be defined at each level of abstraction.

Another way that teams can avoid cost and potentially positively impact their schedule is to reduce the time that teams are waiting to begin activities. This tends to happen when visibility across a development lifecycle is low and access to information is limited.

Using a single source system, like Jama Connect, and providing individual requirement status allows teams to start acting on information as it’s available and ready. As an example, if requirements are accessible and their status is visible, quality teams who handle V&V activities can begin their planning and verification activities much earlier than if they were waiting for documents to be released.

Change is another aspect of cost that’s often overlooked. Change is inevitable as we learn new information and get feedback throughout the product lifecycle. However, the cost of change can be mitigated by identifying and evaluating the impact of that change across the product. Change to a single requirement could impact definition and verification across multiple degrees of separation. Using trace, costs can be avoided by identifying and communicating these impacts early, even before applying the change.

Inform and Justify Decisions to Understand Impacts

In order to balance the three elements of project management discussed here, consider decisions that are being made and the tradeoffs determined during the lifecycle of your product development effort. In most cases, the decisions are working to balance quality, schedule, and cost.

The key to project management is being able to inform decision-making, justify these decisions, and understand the impacts. Properly managing your requirements can inform these decisions by being able to track requirements by their individual state, assess the trace for impacts and gaps, and ensure visibility and communication across teams.

Want to learn more about successfully managing every project? Check out our eBook “Project Management Best Practices” for 21 tips on taking the pain out of project management.  

Jama Connect allows you to create groups to manage permissions and facilitate collaboration at the project level. Groups allow you to work smarter and faster by empowering you to manage notifications, permissions, access and action for multiple users at once.  

There are two types of groups: 

  • Project groups: These groups are created in the context of a specific project and are available to that project when adding permissions. 
  • Organization groups: These groups have no product context; they’re available to all projects in the organization.  

You can name groups according to your internal structure (i.e. job title or work group), by access permission (read-only, read/write), or by role (project admin, review admin).  

Jama Connect comes equipped with several pre-defined project and organization groups, such as Organization Admin, a default group with organization and project permissions. 

Creating groups based on users’ roles or permissions allows you to: 

  • Grant access and role permissions 
  • Initiate reviews 
  • Subscribe users to items 
  • Notify users of changes to content or workflow 

Only your organization’s Jama administrator can determine which people have access to which project. However, as a project administrator, you’re empowered to group your users in a way that makes sense for your project.  

The Users tab within your project will display everyone who has any level of access to the project. (This is the list of users determined by your organization’s administrator.) To create a new group within your project, click Add Group in the upper right. You can change who’s in the group, manage the group subscriptions, change the group name or even remove the group. For stakeholders who work on the project in different capacities, you can also add users to multiple groups.  

Groups aren’t just an easy way to manage multiple users’ permissions at once (although that’s certainly useful!). Groups enable collaboration, provide transparency and visibility across the product development cycle and allow for greater security when required.  

Groups are where the organizational administration of Jama Connect really overlaps with project management within the platform. We recommend identifying high-level groups at the organizational level that are managed by the administrator, like a read access group, and then letting project managers handle the group permissions, notifications and actions within each project.  

For more on creating and editing groups, check out the Ask Jama webinar, or explore the Jama Connect User Guide. 

While every project is different, the same key components for project managers often dictate success or failure: creating realistic expectations, negotiating stakeholder priorities and accurately capturing the full scope of work.  

In a perfect world, these things would all happen seamlessly and every project would finish early and under-budget. But we all know that most often that’s just not the case.  

Whether you’re new to project management or a seasoned pro, take heed of these seven common project management mistakes to avoid missing deadlines, going over budget and contributing to overall project failure.  

Mistake #1: Not clearly defining success prior to starting the project  

If one stakeholder feels strongly that launching by a particular date is the measure of success while another is solely focused on increasing market share, you’re in for a nightmare when it comes to managing priorities and expectations.  

Avoid battling stakeholders by ensuring everyone has a common definition of success prior to kicking off.  

Start by identifying who is most important to this project and defining their interests and expectations. This will allow you to agree on clear and measurable business goals that can be tracked and measured throughout the project lifecycle.  

Mistake #2: Not defining when a product will be ready for release  

In addition to defining measures of success, it’s vital to a project’s success to clearly define when a product will be finished and ready to make its debut before embarking on development.  

When stakeholders have different definitions of when a product is ready to be released, you’re sure to run into tension and frustrations across the board.  

To avoid this, decide what criteria will indicate whether your product is ready for release early in the process. Make sure the criteria are realistic, objectively measurable, documented and most importantly, mutually agreed upon.  

Mistake #3: Making commitments you’re not sure you can keep 

As a project manager, you’re no stranger to mounting pressure. With that said, one of the biggest (and easiest) mistakes a project manager can make is committing to deliverables or timelines that aren’t positively doable. The key here is to have good-faith negotiations with team members, managers and stakeholders and agree on goals that are realistically achievable.  

When things inevitably change (like budget or resources) or you run into unanticipated problems, be upfront and clear as soon as you know that things have shifted.  

Having these tough conversations and realigning commitments with everyone involved is the best way to avoid disappointment and frustration. 

Mistake #4: Misestimating timelines  

Projects never go 100% as planned. However, as a project manager, it’s your job to anticipate what might happen throughout the product development cycle (good and bad) and give your best estimated timeline.  

The good news is that you’re not alone. Many commercial tools are available to help you estimate entire projects. These solutions give a spectrum of possible timelines to help you get a better idea of how things might shake out based on the project’s breadth and depth. 

Mistake #5: Failing to plan for rework after a quality control activity  

Speaking of misestimating timelines… many project managers make the dire mistake of not planning for additional work after a quality control activity.  

While we all hope that we get it right the first time, the reality is that almost all quality control activities find needed improvements.  

To stay on the safe side, great project managers always include time for rework after every single quality control event. The best part? If there isn’t any rework that needs to happen, you’ll be ahead of schedule and you’ll look like a rockstar.  

Mistake #6: Failing to track progress throughout the entire project 

When stakeholders ask for an update on the project, you’ll want to be a specific as possible. This is only possible if you track the progress of the project throughout the entire lifecycle. The reality is, unless you record the actual effort or time spent on each project task — and compare them to the estimates — those estimates will just be guesses. 

As project managers, we sometimes give project updates that are misleadingly optimistic (see above). Remember, you can only manage a project effectively when you really know what’s done and what isn’t, what tasks are falling behind and what issues and risks still need to be tackled. 

Mistake #7: Not learning from past projects  

Expanding on mistake #6, another downfall for project managers is failing to conduct a project retrospective (AKA postmortem) following the completion of a project.  

If you tracked your progress meticulously and thoroughly throughout the entire project, you should be able to glean some vital lessons that you can take with you into your next project. Take note of what went well, what didn’t go well, what surprised you and what you still might not understand.  

This information will help guide you in your next project and allow you to create better time estimates and set realistic expectations.     

As a project manager, you’re the key communication hub between team members, managers and stakeholders. The success of a project can often be directly related to a project manager’s ability to effectively manage requirements and expectations, communicate with all parties involved clearly and concisely and direct the project when adaptations need to be made.  

Want to learn more about successfully managing every project? Check out our eBook “Project Management Best Practices” for 21 tips on taking the pain out of project management.