The Project Quality Assurance Role

Quality Assurance is often seen as an integral function that monitors and coordinates the quality used within the project management life cycle by evaluating the processes and procedures. Quality control, on the other hand, can be seen as a focused area (such as software testing) that compares the product to the specification or plan, with a focus of detecting and remediating errors or anomalies.

Therefore, the Quality Assurance role is a critical factor in the success of the overall project as it is focused on key quality functions throughout an engagement. In his book “Project Management Nation,” Jason Charvat identifies the following key duties for the role of quality assurance throughout the project management life cycle.

The Role of QA on the Project

The person who is responsible for QA has many duties and responsibilities. The following section lists many of the things that a QA person would be expected to do.

• Participate in the change management process to assess the risk of putting fixes into the environment during acceptance testing.
• Assist the test team in isolating the source of discrepancies between expected and actual test results. If the error is in software design, thoroughly analyze the ramifications of any design changes. Design diagrams and structure charts before proceeding with corrections to code.
• Complete preparations for acceptance testing, including the establishment of the acceptance test environment. Unlike system testing, acceptance testing always takes place in the targeted environment. It is therefore extremely important to schedule computer resources well in advance.
• Check the simulated data to ensure that required test data have been produced.
• Obtain expected results from the acceptance test plan and review them for completeness.
• Calculate any missing expected results.
• Be certain that the introduction of new load modules is according to test configuration management procedures. When a new, corrected load module is received, first rerun tests that previously failed because of software errors. If these tests succeed, proceed with regression testing.
• Analyze and report test results. Evaluate test results as soon as possible after execution. Wherever possible, use automated tools in the analysis process. Record analysis procedures and keep all relevant materials. Remember that records and reports should give complete accounts of the procedures followed. If a test cannot be evaluated, note the fact and report the reasons for it.
• Compare all test results with expected results and note that all defects are documented, regardless of how minor they appear or whether they will be corrected.

Project Readiness: Ten Things You Must Do Before You Start

You’re handed a critical project to take and make your own. You finally get to go cradle to grave on it – you’re not just taking on someone else’s mistakes this time. What do you do to get started? Here’s a list of ten must-do’s – in no particular order – that will help ensure that you get the project off on the right foot.

1. Review the Statement of Work (SOW) – This is your starting point and the main document for the project to take off from. It’s loaded with assumptions, expectations, deliverables, milestones, rates, sometimes estimates, etc. It’s your starting point for putting together a decent draft project schedule, draft budget and forecast, and definitely the basis of most of the information you’ll want to cover in a kickoff session with the customer.

1. Identify the necessary resource skill sets for the project and request them – As early on as possible, identify what skills you’ll need for the project. Other projects and other project managers are likely in need of some of the same skilled resources and they’re usually in short supply, so put in formal requests as soon as possible. Don’t request them too early, because engaging a resource before it’s needed can blow your budget out of the water. The challenge is to onboard the necessary resources at just the right time so they’re fully and efficiently utilized.

1. Draft a project schedule – Sales may have provided you with a draft schedule that they worked out with the customer during the sales process. If they did, that may be a good starting point…depends on how competent and technically inclined your sales group is. If not, then start with the SOW and start plugging in timeframes, deliverables and key milestone dates noted in the document. Even if you do get a draft schedule from Sales, always cross check it with this document….ownership of the schedule is yours, not theirs.

1. Hold a knowledge transfer call with Sales – Conduct a call with the sales person or account manager that worked closely with the client to close the deal. They likely put together some of the SOW, drafted a schedule and rough budget and can give you insight on the customer and their key contacts. Those key contacts will likely be part of your customer team so any info you can get before going into the engagement puts you that far ahead to begin with.

1. Call the customer and introduce yourself – Before any formal face-to-face or project kickoff meeting, call the may contact or contacts and introduce yourself. You can maybe even think of a couple of high-level questions to ask them, but save the detailed questions and information for a later face-to-face meeting. This informal introduction call is not the time for that detail.

1. Do an initial forecast of resources for the length of the project – Depending on what kind of information is contained in the SOW, this may be a relatively easy task. Sales had to work out some detail in order to come up with a price for the customer. That’s your budget and it’s likely derived from estimated hours for each planned resource with prices attached to each. If that’s the case, then you’ve got a great start for a budget and forecast for the duration of the project. You’ll have to make calls based on deliverables and milestones on when to engage the resources and for how long, but you can cross check them with the estimated hours from Sales. This will be the basis for the budget and forecast that you’ll manage and share with both teams for the rest of the project.

1. Comprise a list of detailed questions for the customer – Following an initial call with the customer, discussions with Sales, and a review of the SOW, you’ll have some questions that need answers. These will be things you’ll need to know for input into the detailed schedule and how the customer may want certain things run on the project. Getting answers to these questions will help you put together information for your first detailed meeting with the customer which will likely be a formal project kickoff session.

1. Put together a first status report from what you know so far – Taking what you’ve learned so far from discussions and SOW reviews, you can put together your first status report for the customer and deliver it before the kickoff session. Include what you have so far for the draft schedule, budget and forecast. It will go a long ways in building initial confidence in you in the customer’s eyes because it will show that you’re in control and on top of things.

1. Put together a kickoff packet and schedule a face to face with the customer – Using something like PowerPoint, put together a formal presentation that you’ll use in the face-to-face kickoff session. Work with the customer to schedule a day-long session (or however long it needs to be based on your project’s needs) and make sure they have the right people attending (but not too many!). Explain to them that too many attendees lead to too many questions and eventually a kickoff meeting that is derailed and non-productive.

1. Conduct the kickoff session – Hold the formal kickoff session with the customer. Review the SOW, proposed team roles on both sides, deliverables, milestone dates, how and when meetings will be conducted, and discuss the change order process. Refrain from discussing budget items in this meeting unless the customer requests it – I’ve usually had the experience that customers only want certain people on their side privy to budget info.

Balancing Critical Project Success Factors – Engaging Conflicts Directly

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” This is the fifth installment in a six-part series entitled Balancing Critical Project Success Factors. In case you’ve missed the first four, here’s what we’ve covered so far:

• Introduction
• Selling Good Ideas
• Building a Common Vision
• Generating a Commitment to Ideas

In this fifth segment we cover engaging conflicts directly and resolving them efficiently and effectively.

Engage Conflicts Directly and Resolve Conflicts Efficiently and Effectively

Once project plans are underway, change happens. Requirements shift, the client does not meet its obligations in the project plan, and budgets can be reduced. Changes within the IT group can also occur. Tasks may exceed initial estimates. Key programmers leave to join other firms. Differences in opinion among IT professionals about the best approach can erupt into conflicts that push projects off track.

When this happens, IT professionals must assertively engage key stakeholders (e.g., users, user management, IT management) in problem solving about the trade-offs that must be made in quality, time, cost, and perhaps even customer service agreements. Assertiveness is critical because users (and admittedly IT management on occasion) would prefer to avoid making necessary but difficult decisions about trade-offs between quality, time, and cost. Interestingly, resolving such conflicts may be best viewed as a typical and not unusual part of what IT project managers do. In survey research of professional project managers, it was discovered that they report spending an average of 12 hours per week resolving conflicts.

When engaged in problem solving about trade-offs, stakeholders sometimes become frustrated and retaliate by challenging the competence or creativity of the IT project manager. IT professionals sometimes respond to such challenges by retreating from their legitimate interests. In a misguided effort to please, some over-commit to all three factors although significant changes in the project environment necessitate adjustments. The result is priority overload, stressed-out IT personnel, a loss of credibility and influence, suboptimal IT work products, or missed timelines.

Assertively championing one’s basic interests, exploring alternatives with affected parties even when they are not enthusiastic to do so, and collaborating to construct win-win agreements is the better response. Unfortunately, many people drawn to information technology (like many drawn to other technical disciplines) have a personal aversion to conflict. Consequently, for some IT professionals, enhanced negotiation skills is necessary.

Faithfully applying project management disciplines can limit the amount and scope of project conflicts that IT professionals have to manage. Conducting risk assessments early in the project life cycle to identify factors that might threaten project deliverables is one such discipline. If a risk is detected early (e.g., weak user management consensus on requirements) and focused problem solving occurs about what contingencies are necessary to address it (e.g., identifying a resource that can be used to do team conflict resolution with user managers), project disruptions caused by the risk can be effectively contained.

Providing regular user management updates is a second project management discipline. When updates work most effectively, not only is progress reported, but threats to project deliverables are reviewed and user management support of efforts to limit or resolve those threats is secured.

For some complex projects, more substantial organizational conflict management mechanisms are required. On large IT initiatives, the relative priority of the needs of different user groups can change over time. Because IT resources are often relatively fixed, reallocating resources to respond to a increased urgency for one user often means reneging on commitments made to other users. To address shifting priorities between users, some IT groups convene regular, periodic meetings of steering committees or users councils. When such mechanisms work well, users collectively learn about urgent priority changes, explore alternative responses to these situations, and finally make mutual decisions about priority changes and IT resource reallocation. In these settings, IT professionals facilitate the preparation of information that enables these groups to make sound decisions. By promoting quality dialogue between users, IT professionals enhance organizational problem solving.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.

Balancing Critical Project Success Factors – Generating a Commitment to Ideas

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” This is the fourth installment in a six-part series entitled Balancing Critical Project Success Factors. If you’re just tuning in, so far we’ve covered:

• Introduction
• Selling Good Ideas
• Building a Common Vision

In this fourth segment we cover generating a commitment to ideas. The concept is building a commitment to ideas and implementation plans through particpation of the end user.

Build Commitment to Ideas or Implementation Plans through User Participation

Once common vision has been established, successful IT project plans regularly solicit the participation of those who must use applications on a daily and ongoing basis to refine the application and the strategy that will be used to install it. This commitment to participation has several benefits. With greater involvement, user knowledge of the factors that influence timelines and milestones increases, IT-user communication is enhanced and expensive missteps can be avoided and efficiency improved. Participation has a second benefit. It has been consistently demonstrated that involvement with project design enhances commitment to implementation. Giving the user community the opportunity to experiment with prototypes, recommend upgrades, and influence implementation plans early on and often increases the likelihood that the installed system will be well received and ultimately used.

Putting participation into practice presents the IT professional with a few challenges. For participation to work, users must trust the process, view their input as voluntary, experience the process of participating as rewarding, and see their ideas significantly affecting work products. IT professionals may have to intervene to insure these conditions will exist before asking for user participation. This means influencing user management. For user managers to support participation, IT professionals must illustrate that the benefits of participation exceed the risks to productivity created by having their people devote time to project work.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.

Balancing Critical Project Success Factors – Building a Common Vision

In this article I am presenting another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” In the Introduction article we outlined the five prescriptions for preserving the balance between project success factors. In this article, we look at the second prescription – build a common vision of project outcomes and how people will work together to achieve them.

Sustaining Focus and Maintaining Motivation with Common Vision

Once an idea for IT-based performance improvement has been sold to senior user management, effective IT professionals work with those who must live with and use a solution to build a common vision of the performance improvement and how people will work together to achieve it. This is vital because many IT projects are difficult and complex undertakings. Costly technology is required. The multiple factors that influence business problems must be analyzed. Difficult design choices must be made. Complex implementation and maintenance problems must be solved throughout the life cycle of the project. A healthy dose of common vision during the early phases of a project helps guide and motivate both the IT professional and the user through these challenges in later project phases. Rarely does a critical mass of support for an IT solution exist at the outset; it must be constructed from conflicting interests and motives that exist within the user community.

Common vision has two main parts. Common vision describes the outcomes the project is pursuing. It also contains the infrastructure of agreements people develop to guide how they will work together to accomplish the project outcomes. Each is now dealt with in turn.

Common Vision as a Description of Project Outcomes

Common vision is different from a statement of work, although it should inform it as an expression of mission and purpose. In common vision, greater emphasis is placed on the contribution the deliverable will make to the efficiency, effectiveness, or quality of the user’s group (otherwise known as requirements) and less on the features of the deliverable itself (otherwise known as specifications). In a large consulting firm, for example, one might install text-based groupware to help members of the firm in locations across the country identify and retrieve the best parts of proposals used by members throughout the firm. This is a general description of the deliverable. The requirement in this situation may be to dramatically increase the efficiency of the sales process by reducing by half the time its takes to prepare high quality proposals. Clear description of how business results will be different and how users who will be working with the installed technology will be performing differently to achieve those results is a key part of common vision.

One difficulty in developing shared commitments about outcomes is that significant points of difference can exist among users about the requirements. Field sales groups and headquarters sales management within a single sales unit can and will have different and conflicting priorities. Quality control and production units within a manufacturing operation may also have conflicting and competing priorities. Finding common ground in these circumstances requires imagination and insight as competing interests are easier to see than common ones. This insight becomes easier to achieve when one takes time to understand in detail the needs and concerns of various constituencies within the user community.

In the circumstance of high conflict within the user group, it can be helpful to bring user groups together and employ a group conflict management or negotiation process to find a way to address conflicting priorities. IT professionals who pursue this option often find outside experts to facilitate such a session.

If a common vision of requirements is not achieved with users early in a the project, one of important consequences is that downstream project costs are high. Typically, maintenance of an installed IT solution is the last step in the project lifecycle. Unfortunately, 82 percent of costs incurred in the maintenance phase are attributable to problems created in the initial phase of a project — the establishing-requirements phase. Communication problems between the user and IT professionals result in poor specification of requirements. The consequences of proceeding without clarity about requirements is dramatically high system maintenance costs.

Common Vision as a Description of How People Will Work Together

In addition to creating a picture of the targeted performance improvement, common vision also contains agreements about how people will work together on an IT project. Agreements about customer service practices such as responsiveness, decision making, and mutual accountabilities are key issues for which agreements are ideally made. Working through such issues can be experienced as tedious or irrelevant by IT professionals and by users on a project team who are anxious to get to the real work. “Who needs this warm and fuzzy stuff!” is a familiar refrain. The response, of course, is that the project does. Failing to take the time to build the infrastructure of agreements that are the basis of high-performance teams can mean serious derailments later on. When timelines get critical and stress and pressure mounts, tough decisions are required. Teams that are missing a strong infrastructure struggle or fail at such key moments.

An IT group within a major consumer products company now conducts visioning sessions as a preliminary step in all major projects. In these sessions, a vision of the performance improvement is developed, requirements are detailed, and deliverables are clarified. Agreements are also hammered out about how the IT team and the user team will work together. Particular attention is devoted to how parties will notify each other about the need to make adjustments in the project plan and how these adjustments will be approved and implemented.

How to Build Common Vision

Activities which are used to create common vision foster dialogue up and down the user chain of command and within the IT project team about needs, priorities, and requirements as well as the infrastructure of agreements about how people will work together to complete the project. Effective visioning procedures feature detailed meeting outlines and specification of the concrete deliverables that will be created by the common-vision effort. This structure allays user concerns that people will be asked to participate in a directionless “group grope” that will produce general goal statements that specify nothing of real value beyond an understanding that the participants are “all in this together.” Without a solid foundation of shared commitments, visioning devolves into “blue sky” statements about future project deliverables that have little real chance of influencing project outcomes.

The logic of common vision is easy for most to grasp but difficult to operationalize into concrete action steps. When difficult long-term IT-based performance improvement is the mandate, building common vision early in a project’s life cycle about requirements and how users and IT professionals will work together can decrease the priority pressure IT professionals face later in the project’s lifecycle.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.