Ensuring Project Quality – Key Ideas

A project’s ultimate success is attributed to two key factors: the completion of the requirements as dictated by the scope and the inherent quality of the deliverable when it reaches its GA (General Availability) stage.

Whatever the project’s inherent deliverable, ensuring the result of the team’s efforts meets a certain level measure of quality is extremely important from the standpoint of gauging the project’s success. Customers will act quite unfavorably if they have to contend with sub-standard results in the form of a poor quality offering from an organization. Not only could that hurt general sales, but it will garner a poor reputation for the company and damage their standing. First impressions are, after all, everything and being as diligent as possible in fostering an environment that focusses on quality in addition to quantity is imperative.

With that being said, the project manager is ultimately responsible for the resultant quality of the deliverable. Like other factors, such as successful completion of the needed scope, timely release of the deliverable as defined by the schedule and managing the budget, quality is the ultimate measure of the project’s success upon delivery.

So when it comes to ensuring quality of the project’s deliverable, what steps can the project manager take to ensure that quality is not overlooked? What are some of the techniques and ideas to maintaining quality throughout the life-cycle of the project and not simply viewing it as an afterthought or something to be considered during the final stages of the project rollout?

1. The Project Quality Plan

The successful outcome of virtual anything requires good, up-front planning. And quality is no exception. Having a well-defined project quality plan is imperative to ensuring that the end deliverable is going to be at a level that maximizes the enhancements and minimizes any issues. Afterall, customers want to explore all the new ‘widgets’ without having to constantly contend with potential problems in their product. Many a time, a good set of enhancements can be easily eclipsed by a few moderate to large quality problems. Humans by their very nature often remember bad experiences with more clarity and will especially scrutinize problems they encounter.

The actual project quality plan should be part of the greater project management plan and should define up front, how quality will be handled for the duration of the project’s life-cycle. This means scheduling in quality controls and tests, defining quality resources and itemizing a plan of attack should larger scale issues arise. All should be contained within the project quality plan.

2. Monitoring Quality (Assurance and Control)

Once the project quality plan is defined, ensuring that its various aspects are being implemented is vital. Throughout the duration of the project, quality MUST be continuously monitored to ensure that as the product is forming and maturing, any issues that have arisen are addressed accordingly. Quality should NEVER be left to the last-minute, even if time in the schedule is allocated to a full testing cycle. The main reason is that, while a defined schedule release cycle is likely valid, issues that arise have an additive effect. Also, regressions are harder to gauge if the focus is entirely on the new attributes of the product and most of the quality assurance is simply unit testing. As with anything, do not make assumptions about the quality of the product during the project implementation phase. One can get into the habit of just simply verifying that the new features are working as expected while ignoring other issues that manifest themselves.

3. Quality Tools and Processes

Like many other things, we are often only as good as the tools and methodologies we adopt to do our jobs. And quality is no exception. Various things are available to help team members and the project manager continuously monitor and verify project quality throughout its release cycle. The tools themselves can include both actual tools for the testing of quality, such as test harnesses, test case tracking and bug systems, analysis tools, et cetera along with the measurement tools or concepts that are also available. Some of those include things like Pareto Charts, Ishikawa (or ‘fishbone’) Charts, scatter diagrams or burn-down or ‘trend’ charts of bug control and closure. Note that there are also entire processes that are available for focusing heavily on quality. Sig Sigma is a very strict process whose entire purpose is to ensure minimal defects in the end deliverable by adhering to the notion of having only 3.4 defects per million units shipped (99.99966% defect free). ISO9000 is also a family of standards that are very focussed on product quality and achieving this certification is a demonstration of the company’s commitment to a philosophy of high standards.

4. The Alpha and Beta Release Cycles

While this is somewhat more prevalent in software (and hardware circles), it is worth noting here. The idea behind these release cycles is that the product is provided to a set of predefined customers who will exercise the product in their own environment to gauge its new features, provide feedback and assess any issues they have encountered. For those familiar with how movies are made, this is akin to the ‘dailies’ where filmmakers will showcase un-edited footage of their movies to a screening audience to gauge their sentiment and reactions. Similarly, the alpha and beta release cycles are the ‘dailies’ of the quality management area.

For further granularity, the actual definitions of the two cycles are dictated as follows:

Alpha Release – The deliverable is made available to a set of target users, usually internal to the company but not directly related to the product itself. They may be members of another team or maybe a set of senior level engineers who did not work on the product but are familiar enough with its workings to be able to successfully screen it. Note that projects can sometimes have more than one ‘Alpha’ cycle and the number and type of those cycles is varied. Usually, how many will occur is dictated in the quality management plan.

Beta Release – The deliverable is made available to a set of users in the broader external community outside of the organization. Beta releases are usually provided to individuals part of the developer ‘network’ as opposed to the average consumer. For example, Microsoft’s’ MSDN (Microsoft Developer Network) is often given Beta versions of software that is slated for future release. These individuals will have a first look at the new offering and give feedback to the company and file any issues they have encountered. The Beta Release Cycle can be both a blessing and a curse. While it is good to be able to utilize customer feedback to better gauge the success of new features for the product, it can also lead to problems if the Beta release itself is full of issues. So it is imperative that the Beta release still be treated with as much regard as the GA or General Availability release. The Beta is, after all, the first impression and most companies will want to ensure that it meets the highest quality standards it possibly can.

5. Quality Follow-up

Once a product is eventually rolled out, the project itself has completed its work on the deliverable. However, it should be noted that a project should NOT be closed immediately post-release of its deliverable. Invariably, it is extremely important to provide quality follow-up for any issues that emerge that were not otherwise caught during the standard testing cycles or the alpha/beta release cycles. While customers can be forgiving for ‘minor’ issues that may have manifested themselves, they are likely not going to be very patient if the company turns a blind eye to these issues or does not provide follow-up adjustments in the form of workarounds or patches. So the quality management plan should have some provisions for monitoring product quality post-release and have action plans and processes in place for any follow-up ‘fixes’ that may need to occur.


Quality should never be considered an after-thought. New widgets in your product are great. Beating a competitor to market can be a boost to your company’s bottom-line. But if all of that is achieved at the expense of quality, the long-term ramifications could be dire. As such, it is imperative for the project manager to keep a close eye on over-all project quality, ensure that a quality management plan is in place and convey to the team members how quality will be handled for the duration of the project. One only needs to review historical cases of products coming to market that were innovative but were disastrous from a quality perspective. Those situations must be avoided at all costs to ensure the reputation of the company is not tarnished.


The Feasibility Study – Key Factors

Projects come and projects go. Some succeed and some fail. Some result in lucrative windfalls for the organization. Others languish in purgatory for years or decades producing little to no value add over the long-term.

Regardless of outcome, whenever a new project is being considered, the invariable question that comes up is whether or not the project is actually feasible? What steps should the project manager (along with other key stakeholders take) when evaluating a new project to determine whether or not they can (or should) move ahead with it?

There are several key questions that should be addressed by the project manager, the sponsor and the stakeholders when examining whether or not to proceed with a project. Some of those key factors are:

Business Alignment

Whenever envisioning something new, a primary question to ponder is: does this project (and its ensuing deliverable) correspond with the broader mission statement of the company? It’s an important question to ponder since attempting something ‘new’ or ‘radical’ can sometimes lead to great success or dismal failure. What is imperative is that when assessing the viability of a project, it is important to ensure that it aligns well with the business initiatives. If, for example, your company is moving to a very focussed .cloud route, projects that fall into that scope should be given precedence. Conversely, if your company is strictly software focussed but the project calls for hardware design and implementation, than that needs to be scrutinized. Whatever the scenario, it is important to ensure that the project is in the best interests of the company moving forward and that it’s implementation has some tangible benefits down the road.

Technology and System Assessment

Once initially scoped and brainstormed, it is important for the project manager to determine the technology viability of the proposed project and its deliverables. In many cases, the individuals brainstorming a new idea or concept may not have the requisite technical know-how to be able to gauge whether the resultant solution is possible, given the technology of the time or the capabilities of the company. So when scrutinizing the proposed project, the team and stakeholders need to ensure they have several more senior technical consultants provide input. There may be situations where the project can proceed but requires a partnership with an external vendor. Additionally, certain contractors with specific skills may be needed and their inherent cost needs to be considered. In any sense, having a firm grasp on what can be done is important and this needs to be well-known up front. Otherwise, the project could end up dying half way through its implementation because a key technology constraint was not considered.

Economic Viability

When looking at how to proceed with a project, it’s necessary to look at the full impact of the project from an economic standpoint. That entails determining the estimated costs of implementation, the projected return on investment and the market niche being targeted and saturated it is. If the project is looking to produce a deliverable that has some intrinsic function that the company wants to be part of its broader portfolio, that is something that needs to be considered. Cost/benefit analysis as well as SWOT and market analysis performed by Product Managers can provide a good assessment of the economic viability of a project and should be part of the overall feasibility study.

Operational Considerations

When looking at the project, what has been scoped and the inherent requirements listed, it is important to ask: does the proposed solution adequately solve the problem or fill the niche in the manner expected? In certain cases, a proposed project under consideration sometimes provides a solution that is tangential to the expectations of the end market and as such, is not fully viable in its current form. By reviewing the operational considerations thoroughly, one can make a more informed decision as to whether the existing deliverable is the end result every wants or does it need to be redesigned or re-scoped.

Legal Ramifications

Whenever a project is under consideration and has certain features scoped, it is important to determine if there are any legal issues with the current implementation. Some of those areas of concern might be government regulations (foreign and domestic), patent infringement issues, company compliance measures, and so forth. Understanding what (if any) legal considerations need to be addressed is important to ensure that the project does not run into unexpected roadblocks in its implementation.

Schedule and Resource Concerns

Arguably one of the most important considerations for the feasibility study, how the project affects the timeline of other release trains and how adequately it can be staffed is of vital importance. Whenever scoping a project, the number of resources and initial schedule estimates should be referenced against existing projects. What impact, if any, will implementing the current project have on other projects? Will schedules slip or have to be pushed out if it is enacted? And will the necessary resources be available for full implementation of the project? All are important considerations to ponder whenever performing this portion of the feasibility assessment.

**Some Additional Considerations**

Market Dynamics

Whenever looking to implement a new project that involves some type of to-market deliverable, it is important to look at market trends to gauge how viable the product will be. Are there other solutions out there that already have a head start? Does the current solution provide something ‘new’ or ‘unique’ in relation to its competitors? Is the current implementation up to modern standards or is it based on technology or concepts that have become stale? All of these need to be considered in the feasibility study.

Company Cultural & Political Concerns

Finally, when looking at the project, a consideration is to also look at the company and its overall culture and functional directive. If the project is a process methodology change or some fundamental shift in the internal way things are performed internally, that has to be approached cautiously. Whether it be adopting an Agile process, implementing a new Change Management System, or performing a portfolio shift, the sentiment of the company and its current culture need to be taken into account.

In closing, it is always important to determine up front whether or not it makes sense to move ahead with a given project. Projects that are taken on full tilt without up front feasibility discussions could end up wasting copious time, money and resources that would have been better suited in other areas. This can lead to missed revenue estimates for the company or sub-standard deliverables.