Is QA Improving Your Project Performance?

The Quality Assurance (meaning process, not test) team is critical to PM Office performance and optimization. In fact, it isn’t possible to operate a truly effective PMO without an equally effective QA organization (whatever its title). QA functions exist to help performing organizations (like the PM office) form baseline best practices into lean and easy to use procedures, templates, checklists, and other tools, and then to track their compliance and facilitate performance improvement. In too many cases though, these facilitators become process dictators, and real quality performance suffers as a result.

The best QA’s are expert facilitators that 1. guide performing organizations to measurable performance improvement,  2. engender a positive culture of quality, and 3. reward those in the PM Office that show a commitment to excellence and/or produce real performance improvement. Top QA teams position themselves as support (enabling) organizations to the functions they seek to improve. It has to be this way, since the entire reason for the QA to exist at all, is to elevate the level of excellence achieved by other functions (like the PMO), and not the QA itself.

In fact, the QA role could be compared to that of a trusted and capable assistant to a top level executive. The assistant exists to enable the executive, not to act as a stand in or replacement, and not to provide independent leadership. Similarly, the QA function exists to assist PMO organizations and PM’s in optimizing their performance, but not to replace or stand in for them when it comes to defining “how they do what they do” and/or “what metrics they use to gauge success”.

That point is worth making because in too many organizations, the QA team steps outside the role of an enabling organization, and into a governing role – big mistake. In these situations, QA takes a leadership role in how process is written, how performance is measured, and how compliance is enforced. In effect QA is allowed to dictate how the performing function (i.e. PMO) does its work, often with executive management supporting this unnatural order. So what’s wrong with this approach?

Of course the PMO will still be held accountable for project outcomes and performance, so they’ll have to serve 2 bosses, 1. The QA team in terms of keeping up a set of artifacts, reviews, and other activities required to show compliance, and 2. Executive management in terms of real outcomes and performance. This inevitably produces cynicism within the PMO instead of a culture of quality and sends the message to them that they aren’t trusted to produce project excellence. As a result, PMO staff will pay lip service to QA standards while working around them, and will never take responsibility for process and/or process improvement. It’s executive management’s job to delegate authority and establish accountability, and in this kind of dynamic, they’ve laid a solid groundwork for mediocrity. There’s no way to interpret such outcomes as anything less than a complete failure on the part of executive management and QA.

When the QA team is allowed to assert authority over front line PM office leadership, it results in reduced performance and a general lack of respect for QA and process. It sends the message to project managers, that executive management places its trust in their compliance to process written by others, as opposed to the PM’s personal accountability for the outcomes they produce.

That’s why the PM team “must author and own the procedures they follow”. QA is there only to drive compliance to process and closure on improvement actions. This forces the PM’s to become partners with QA in quality, to take responsibility for process and related outcomes, and engenders a much greater degree of buy in and support for QA and process within the PMO.

So what should happen? Executive management must limit QA responsibility to management of the quality management system (process, templates, …), performing audits and other compliance activities, and root cause/performance improvement efforts. The processes, templates, and other quality tools themselves must be owned by the PM office, who should be held accountable for the outcomes they produce. That forces PM office personnel to take ownership for their own performance and performance improvement since they know that executive management expects them to show real progress in those areas. By contrast, the QA team plays the role of an independent third party reporting on compliance and improvement activities.

In the final analysis, while the QA is about “PMO quality and performance”, the job of achieving real gains in “quality and performance” is not about the QA, it’s about the PM office. Executives that understand that dynamic are in a much better position to engineer an organization with the right built in motivations and priorities.

At PMOSoft, we provide the PM Office information and quality management systems (web applications & procedures) needed to help our client achieve the PMO mandate in as little as 3-4 months. Please visit us at http://pmosoft.com to learn more.

Agile is No Substitute for SDLC

Agile software development, as defined in Wikipedia, “refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams“.

Many articles, blogs, and discussions have been written over the past few years regarding the benefits of Agile development. In fact, as a management method, Agile has peaked as the latest fad to sweep software management consulting, and as a result, it has become very popular with IT/development managers. Is it just a fad? Perhaps in some ways, but its value can’t be understated when utilized for the right type of project and under the right circumstances. Specifically, Agile targets small software projects with teams of 10 or fewer, which are focused on the delivery of user interactive software. In these projects, the customer is often better able to fully envision/specify final product requirements through a small series of prototype iterations.

While the need for Agile is real and clear for this kind of development effort, I do wince every time I hear some consulting organization promote Agile as an alternative to SDLC (Software Development Lifecycle).

In fact, the Agile methodology is only applicable to a few project types and lifecycle phases (namely software design, coding, and unit test) within the overall SDLC, and finally, it is very “design/coding focused” in its aim. Agile is a concept produced by software designers/coders for software designers/coders, rebelling against strict waterfall methods that held them accountable for highly accurate requirements and design plans, in situations where iterative passes at requirements and design made much more sense. It quickly became obvious to many, that Agile was a clear improvement for a subset of smaller projects, focused on more user interactive products, and better served by an iterative process.

Agile adheres to a unique set of core principles (listed below) that define its purpose, but it’s important to understand that while those principles are a good match for some of the software development efforts described above, they’re in no way universally advantageous. I’ve provided some competing considerations for each, in an effort to underscore their limits.

Agile Principle		Competing Considerations
—————————-		————————————————-
Individuals and interactions over process & tools		Advantageous for small projects with straight forward single dimensional software deliverables.
		Can really get you into trouble as requirements and / or design size and complexity increases.
Working software over comprehensive documentation		This is no different from SDLC – great documentation is only a goal in as much as it drives quality in software and software related deliverables.
		A poor SDLC management culture can skew quality priorities to the point that it may seem as though the documentation is “the point”, but like any methodology (even Agile), it is only as good as those who use it.
		When requirements come up front or result in a complex design or system of designs, then cycles of documentation and review are absolutely critical to 1. success at any level and 2. achieveing the level of quality required.
Customer collaboration over contract negotiation		An oxymoron if contracts exist at all – contracts/other agreements must allow (enforce) the Agile management dynamic in a way that doesn’t increase risk for the software producer.
		Potentially disastrous if they don’t and you’ve taken shortcuts in documenting requirements.
Responding to change over following a plan		Perfect where the customer priority is the quality of the outcome, especially when they aren’t clear on what that outcome should be when the process begins.
		A recipe for trouble when dates and quality are both important. Which is almost always the case.

Given that Agile is limited to a subset of project types and SDLC phases, it follows that Agile cannot act as a replacement for SDLC. In fact, Agile isn’t a comprehensive project methodology at all, it is a component methodology. As a result, a large system development effort may be separated into a number of individual user focused design efforts that use Agile during development, while other design subsystems within the same project follow SDLC, even for the design, coding, and test phases.

Agile only makes sense as a component of an overarching end-to-end SDLC model despite the tendency of consulting organizations to expand the scope of Agile in an effort to extend the scope of their consulting engagements.

My purpose for writing this piece is to continue to challenge management executives to exert due diligence when it comes to the selection of contract professionals, methods, and the use of consulting organizations. Management methods and tools must be applied to the specific problem space they were designed to address, to avoid poor or even damaging outcomes.

Despite the claims made by some consulting professionals, Agile cannot replace SDLC and cannot meet full lifecycle needs. Agile may in fact be a superior process approach for the software projects you manage, but it only solves part of your project / lifecycle problem. You still need an integrated project level SDLC framework (perhaps with both agile/waterfall component development methods) to manage project initiation through planning, and post development lifecycle activities.

At PMOSoft, we provide the PM Office information and quality management systems (web applications & procedures) needed to achieve the PMO mandate in as little as 3-4 months. Please visit us at http://pmosoft.com to learn more.

Aligning PM Collaboration Systems & Standards

Project customers and executive stakeholders operate in a highly competitive market and are under ever increasing pressure to deliver more value, more quickly, and with fewer resources.  Knowing that the promises made by sales and product management, must be kept by PM teams, they look to the PM office for competitive solutions. The PM office is responsible not only for delivering on commitments, but also for building the delivery reputation that will lead to repeat business and increased customer loyalty. Nothing is as critical to customer satisfaction and loyalty (or future sales) as an efficient and high quality delivery experience at the hands of a truly professional PMO.

To win in the quest for performance excellence, the PMO can rely on two key weapons, 1. QA standards (policies, procedures, metrics, …) and 2. Collaboration systems (CS). This is common knowledge and many PMO’s do their level best to meet the challenge. The difficult reality however, is that many fail to realize their vision, due in large part to a failure to synchronize the standards and tools within these two complex and inter-dependent solution spaces.

QA standards exist to ensure consistent and improving project management performance and product quality while collaboration systems exist to increase productivity. Top PMO’s consistently align their CS platform to conform to and enforce their PMO standards, thereby setting the stage for world class performance. A simple but very effective formula that is the hallmark of the best in class PMO.

So what’s the catch?  While QA standards are tailored by each PMO to meet their specific needs, one size fits all PM collaboration systems are not.  CS platforms are delivered as finished goods based on fixed process and data models that don’t align with any given PMO’s existing standards. CS that do provide some level of configuration flexibility are expensive out of the box, but implementation costs, duration, and complexity increase dramatically with the amount of flexibility offered. As a result, synchronizing a standard with a collaboration system can be extremely challenging, time consuming, and expensive.

In addition, the risk of failure increases with inexperience. While well synchronized CS and standards systems vastly improve performance, poorly synchronized systems have the opposite effect. For this reason, it’s critical that PM organizations exhibit a great deal of care and due diligence in platform selection and configuration. Otherwise, they face the specter of having spent a great deal of time and money only to end up worse off than they started.

In order to meet the challenge, the QA-PMO team must make process engineering and improvement the top priority. CS (tools) must be driven by process and not the other way around. QA process cannot be constrained by the limitations of an off-the-shelf (OTS) PM collaboration system, without suffering in terms of its effectiveness in improving PMO performance. Instead, the CS must act as an extension of PMO process, no matter what form it takes. The CS must be tailored to facilitate PMO process and information requirements, and be able to change with them over time. This may (and often does) force development a custom CS solution, or force the decision to delay the adoption of any CS at all. It’s that important.

As a result, you won’t be surprised to find out that most top PMO’s, only get to be top PMO’s because they exist within large organizations with the deep pockets needed to support expensive in house solutions. It makes them very difficult to compete with. That said, smaller organizations can achieve most of these capabilities through disciplined adherence to a well conceived long term evolution plan, provided they have the architectural and planning expertise in house. Such an evolution must always begin with standards definition and compliance, and finish by reinforcing those standards with intelligent CS development and integration decisions. CS acquisition/development is by far the most difficult and risky step.

Building a top PMO is difficult but, not impossible. I’d offer this advice to most PM office leaders serious about engineering a solid operational evolution path:

• Focus 1^st on standards definition and compliance, and don’t worry about the CS solution until you’re satisfied that your QA discipline and culture is working, healthy, and improving
• When it comes time to begin work on a CS solution, build your CS requirements / selection criteria based on the minimum requirements of QA standards. The CS should provide elegant standards automation, enforcement, and be able to support standards evolution.
•  Use off-the-shelf if a satisfactory solution exists, but don’t be afraid to consider a custom solution if the business case will support it.
• Get help. PM office organization and automation is very complex in terms of definition and implementation, which pales in comparison to the level of expertise required to introduce the change within your organization. Initiate detailed discussions with multiple firms, and move when you know it’s right.
• Treat the process like the most challenging project your PMO will ever face – you won’t be far off the mark.

Finally, don’t try to boil the ocean, solve world hunger, … pick the colloquialism you like best; the point being, it’s fine to develop a comprehensive end CS solution and evolution path, but when it comes to implementation, move forward in small increments. Build the PM office one value added sub-system at a time, to allow yourself to learn as you go and validate your results a piece at a time. That may help to identify any misdirection early on, so that appropriate review and re-vectoring can take place to achieve the best possible end results over the long haul.

PMOSoft provides synchronized PM Office information and quality management systems (web applications & procedures), and consulting expertise needed to achieve the PMO mandate in as little as 3-4 months.  Please visit us at http://pmosoft.com to learn more and call us when you’re ready to take your PMO to best in class.