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.

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.

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.

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.

If a team of individuals are allowed to operate independently, each using their own unique methods, the result will be a different performance for each project managed. No consistency from PM to PM or project to project, and your quality guarantee is only as good as your weakest performer. Furthermore, unless an individual PM follows his/her own written script each time they manage a project, even the individual will produce inconsistent outcomes project over project. In this situation, the PMO cannot help but fail in its mandate to establish consistent and improving project performance and product quality.

Based on these facts. It becomes clear that written process:

• must be produced and complied with to ensure repeatable/consistent management outcomes
• must borrow from the individuals that routinely produce the best outcomes for the specific work being scripted

What is needed, is a team of individuals that all bring their own unique talents, skills, and approaches to a shared system of optimized procedures.

Is that it? Hardly. No process will ever be put to its best use unless those responsible for following it are entirely bought in to its use. They must believe. That means each process must be written by its users (to engender personal ownership) and they must be held accountable by management for its failures and rewarded for its successes. Since people generally do what they’re rewarded for, management must show a keen interest in process development, compliance, and performance. Employees must realize that as long as they followed process thoroughly, they will not be blamed for a poor outcome, but instead, the process will be questioned and reviewed for potential corrective action.

So where do lessons learned (LL) fit into the picture? Let’s first classify each LL as a positive or negative lesson. The question becomes: how do we repeat the positive lessons and avoid repeating the negative lessons in future projects? The best answer of course is by altering written process to institutionalize the learning.

LL gathering should be a requirement of written PM closure process, while LL resolution must belong to PMO QA improvement process (resolution is not a function of the project). If there is a real lesson to be learned, then it’s that the best response to a lesson learned is an update to permanent process so the lesson response isn’t simply discussed, only to be quickly forgotten.

I’m going to break with long winded tradition and end here, but I will leave you with the following declaration: no PMO can achieve its mandate for consistent and improving project performance and product quality without process and process improvement. The value process actually delivers, depends on how well the culture of quality takes hold within the adopting PMO.

The reason for this is that the project schedule is the most visible part of any project plan. The first question on everyone’s lips is always, “are we on schedule”? The assumption, of course, is that quality is a given in any answer to that question. Therefore the statement, “we’re x days behind schedule”, translates to “it will take us x days from this point to complete all deliverables due today in full compliance with all quality and workmanship requirements”. It’s just the way we think about progress.

OK, but how do you keep a schedule simple but effective? Well let’s start with some basic ideas. First of all, time is made up of some pretty small increments at the low end, so you have to decide just how granular you really need to be. Do you need to manage in minutes, hours, half days, days, or weeks? Second, how much freedom do you want to give your team members from micro-management? To manage in daily increments, for example, would require daily updates from team members. Finally, how long is the project (let’s assume it isn’t really a project unless it at least six months in duration)? Taking these questions into account, the work week often surfaces as the atomic schedule increment of choice (some exceptions will often exist for specific types of activity).

Don’t get caught up in tools based scheduling provided by tools like MS Project. These tools do a great job of managing the schedule down to the hour and minute, but that level of detail will just confuse your stakeholder community.

Keep reports simple (and very concise) if you want your stakeholder community to actually read them and stay involved.

 Using the work week significantly simplifies schedule management, making all non-critical-path items due on the Friday (or any fixed week day) of the week in which they deliver. Since nothing is late until end of business (EOB) Friday, schedules may be tracked using simple week numbers (1-52) instead of more granular daily dates (mm/dd/yy). The use of week numbers eliminates the need to check the calendar in most cases. Mercifully, this approach also leaves the weekend as a built in grace period when being late is just too undesirable. It’s nice to have a second chance when things suddenly go south at the last minute.

As the PM, employing a once a week update sets the tone with team members that they are completely in control of their week (no micro management), with no interference until Friday when a reforecast/deliverable is due. If they fail to deliver at those points, then their work suddenly becomes very visible in status reporting (not good for anyone).

Aligning status reporting to Friday EOB snapshots simplifies reporting for all team members, executives, and stakeholders as everyone quickly learns to manage to the snapshot. Team members work to put their best foot forward and provide the most accurate view possible in time for each snapshot. At the same time, the noise level associated with status queries from management disappears as they work to the regular weekly update, leaving your team to be more productive.

Of course, missing a Friday due date should never be a surprise. Weekly or regular status meetings should identify any schedule slippage well in advance of the due date. Those delays should be captured in status reports along with any corrective actions being taken to remedy the situation. Response actions should be escalated to management when management intervention can help in ways the team cannot. This gives management a chance to intervene and assist with additional resources or other steps at their disposal. Sometimes a delay can’t be avoided, but it’s unacceptable when raised too late for management to react effectively.

There are other rules of thumb related to simplification that tie very well into a weekly assessments and deliverables schedule. As an example, it’s also useful to size the duration of bottom level WBS components to increase the  accuracy of estimates and limit the size of schedule misses. A choice of 3-4 weeks is optimal for many projects/situations, but can vary base on the type of work or the management culture in which the work is being performed. Using a 3-4 week standard, a 16 week assignment  will be divided into multiple 3-4 week tasks, because the PM has learned that SME’s are more accurate when estimating and meeting schedules for tasks of this size. This effectively amounts to load balancing from top to bottom of the schedule and WBS to simplify estimating, reporting, and comprehension of the project schedule.

Activities and tasks often size themselves with little room for PM manipulation, but overall project success, especially in large projects, is based more on the PM’s ability to create many very small successes than any other factor. The PM can play a major role in ensuring those small successes by limiting complexity in scheduling and sizing tasks in a way that “sets each team member up for success”.

 PMOSoft provides the 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.