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.

Institute of Change Management: are you in it?

I got my login details this week for the Institute of Change Management; I was pleased that my membership has been approved.

To be honest, logging in to the Institute’s website as a member doesn’t give you much access to extra stuff.  There’s a forum, but the community is still growing so at the moment you don’t need to be a member to look round the website and see what it’s all about.

The good thing about signing up and becoming a member is that the Institute of Change Management (IoCM) is the only professional membership organisation in Europe dedicated to managers charged with organisational change.  Like us.  If your project doesn’t involve change then it’s not really a project.  The IoCM doesn’t focus on technology or construction or any other project management field: it’s about making change stick and leading the evolution of the change management profession through recognition of the particular skills and knowledge required by change management practitioners.  The idea is that the membership and community will grow, and the Institute will support individuals and organisations through educational programmes, expert consultancy, and access to the latest research and thinking.

The IoCM is based at the University of Brighton’s Business School and funded by the University’s Commercial Activation Fund.  It’s taken about four years research and development to get the Institute to this point.  It was the result of discussions with groups of alumni from the University’s MA Change Management Programme eager for their profession to be recognised on a national scale.  Given that there are only two other change management organisations in the world, they thought it was worth having a European-based organisation to champion and oversee the standards of change management.

The Institute launched in July last year, so in terms of professional bodies it is still new.  That explains why the website isn’t that developed in terms of resources for members. On top of that, it is free to join, so while they are building a membership base and interest the resources provided necessarily have to be relatively cheap, I’d imagine.

Still, there are huge benefits of being in an Institute like this at the ground level.  Members will be kept abreast of developments and as the membership group is smaller we’ll have the chance to network in a more effective way with the decision makers.  Change management itself isn’t new – Brighton’s MA course has been running for over ten years and is targeted at experienced managers wishing to further their skills.  That’s the kind of person that the IoCM will attract, so if that sounds like your kind of community, and you’re based in Europe, then sign up for membership now!

Project Management: How to Successfully Kickoff a Project

In my article titled “The Project Kickoff” I discussed how the project manager should handle a typical project kickoff session with an external customer on a sizeable engagement. In that post I covered what happened in the Kickoff phase – Phase 1 of the overall PM methodology I presented over eight articles and in summary form in “A Quick Guide to Project Management Methodology“.

One can say I use PMI, etc., but that doesn’t really tell the story. PMI provides the common terminology and practices, but what it doesn’t seem to do a great job of is laying out an entire PM methodology…one that you can follow, build a project plan from that means something in the real world, and manage the project and team from. The Quick Guide I laid out does allow that…and here I’d like to talk more about how the project manager successfully kicks off a project.

The Assumptions

For the purposes of this discussion, we’re going to assume that the project we’re talking about is visible, high dollar, important to your organization, and is for an external customer. Internal customers need a kickoff session, but it’s not usually too elaborate nor does it require as much preparation…funny how that works but the external customers often get top priority, the most attention and the best resources…especially if they’re paying decent money for the project. We’ll also assume this is for some sort of enterprise software solution that your organization offers.

Dropped in Your Lap

So a large project has been passed from Sales to the PMO and your PMO Director has dropped it on you. Now what do you do?

AT this point, Sales has completed their part of the process and you likely have a Statement of Work (SOW), rough resource estimates, specific contract dollar amounts, and a rough project schedule or at least milestone dates in front of you. Whatever you want to call it – kickoff meeting, planning meeting, strategy session – you must hold a face-to-face with the customer to go through these items and ensure that, now that Sales is out of the way, everyone is on the same page. Trust me, it’s not a given and depending on how your organization is run, it’s not even very likely. If you’ve read enough of my articles you’ll understand what I mean – remember when I found my business analyst crying in the hallway? If I’ve learned anything, it’s that you should never assume anything. There…that’s one of my BIG lessons learned.

Wrap Your Arms Around It

In order to prepare for the face-to-face, you first have to get your arms around what you’ve been given. Meet with Sales, go through the SOW with a fine-toothed comb, and review the pseudo schedule and budget that Sales likely passed on to you – and then make them both your own. And by that I mean re-create them how you want to manage against them. Beef up the project schedule with what you know must happen…Sales doesn’t have that PM detail in their heads of what happens on typical projects and neither did the customer when they were meeting with Sales. The onus for that is on you.

The Presentation

For the face-to-face, I always suggest a more formalized meeting to review the following in at least some detail:

• Statement of Work
• Draft project schedule (now with your revisions)
• Milestone dates (pull them from the schedule and review separately so that everyone is very aware of the key dates)
• Budget (if this is appropriate given the attendees and your customer’s preference)
• Your PM methodology (let your customer know how you plan to manage the project)
• Your change order process/change management practices
• How you intend to handle risks/issues
• Status calls and status reporting schedules
• Initial list of risks (if you’re prepared for this at this point…otherwise wait till you have your first status call)

Prepare a presentation deck and get it to the customer for review and agreement prior to the meeting. It will make for a much more successful and productive kickoff session as they’ll already have their questions ready for you – or even answered beforehand – thus, ensuring that uncertainty doesn’t extend into the Exploration phase which comes up next.

Who Should Attend

Face it, you’ll be outnumbered no matter what. I suggest this 1-2 day session should be held at the customer site and they’ll probably try to bring everything but the kitchen sink so be careful. Get a list of their proposed attendees and try to work with them to trim it down. I once had more then 30 customer attendees in a kickoff session and it nearly turned into a fiasco. We were able to trim it down for the 2^nd day, but I’d advise – as a lesson learned – to try to do that before going onsite.

At a minimum, here’s who should attend:

Delivery team:

• Project Manager (that’s probably you if you’re reading this)
• Business Analyst (ideal if one has been assigned…and if one isn’t assigned immediately after you acquire the project, scream! You’ll want their technical expertise available at the kickoff meeting)
• PMO Director (this attendee is not critical, but with a visible, high $$ project, they’re going to want to be there or will be forced to be there by the CEO)

Customer:

• Project sponsor
• Relevant SMEs that have or are defining more detailed requirements and business processes and know what the end users need (and may be the end users themselves)
• Customer Project Manager (often this person is more of a hindrance than a help, but if one is assigned, they need to be present)

Beyond that for the customer and you’re probably going to have too many. Remember, the SMEs are NOT one person…that’s probably 10-12 people depending on the size and type of your enterprise implementation.

Summary

Following these steps will usually ensure that you’ve brought the right people and information to the table to go through the details and get the project started off on the right foot. And it’s extremely important to do that as you’re likely to have some expectation resetting to do….Sales sets one expectation, but yours is the more important, and realistic expectation. Make sure you’re well prepared, well represented, and a little bit stubborn.

So How Did You Become a Project Manager?

I’d really like people to answer this one for me….so please get ready with your comments. It’s a much more recognized field now than it was 20 years ago so you now actually see people getting degrees in project management and planning a career in it. But that definitely wasn’t the case 20+ years ago – at least not for me. What’s your story? I’d like to hear it and everyone else probably would as well. Tell us. Here’s mine.

How Brad Egeland Came to Be a Project Manager

Ok, this is not going to be an adventure story – that’s for sure. Some of you may already have heard some or all of this before because I think I’ve already included some info about this hidden in a past article somewhere. But, for the new readers or the ones who just can’t get enough of this info (yeah, right?)…here goes…

My father came straight out of college and started the IT department in the 1950’s for a large Midwestern grocery store chain based in my home town. I told him growing up that I was not going to have anything to do with computers. I even continued that stance as I started working for him after I turned 16 as a computer operator running card decks through card readers and loading large backup tapes on tape drives (and lots of mischievous things late at night in the warehouse involving the golf carts that the security guys would use to go from station to station….ah…good times!).

In fact, I was going to be a pharmacist (why?). I even started out in pharmacy my first year in college. Nothing against pharmacists…my brother is a pharmacist…but that just wasn’t for me. I moved over to the business/MIS track and took one – count ‘em – ONE programming class…COBOL. That landed me my first job right out of college in the mid-80’s as a COBOL mainframe programmer and guess what, I was doing something with computers. My dad was right…again. Oh well.

Application Developer

I quickly became a system lead on a large government contract – the organization I worked for primarily bid on and won large education-related government contracts. We’re talking in the $100-200M range lasting 3-5 years. So there was a lot of opportunity for responsibility fast…and a lot of opportunity to play significant proposal roles in winning new contracts…which led to opportunities for new roles on the new contracts.

First Manager

I also should mention that I had a great friend and manager at the time – he’s now a CTO in Minnesota, but he was a great career mentor to me back then and could see I wasn’t the type who would be happy coding 8-10 hours a day forever. He helped me shift gears, move into proposal roles and then into roles on new contracts that placed me in line with program and project management responsibilities. My first move from development was to a configuration manager role on a new contract our company had stolen from the incumbent.

From there I moved into multiple project administration roles (managing program budgets, change orders, configuration/change management, and financial forecasting) on contracts before accepting a key contract position as a Deputy Project Manager on a 5 year education contract. This was my first true ‘management’ role with actual hiring/firing/etc. responsibilities over resources – and also made me the youngest true manager in the history of the company at that time. That’s changed since then as they’ve grown and the need for actual managers has grown as well.

The Big Jump

Since moving into the role of Deputy Project Manager in the early 90’s I’ve had various PM and PMO roles and responsibilities – my last 18 years have all been filled with project management and PMO leadership roles. The organizations have changed, the industries have changed, the types of customers I’ve served have definitely changed, but the principles that guide me in my PM work have remained the same – those characteristics of a project manager are applicable to whatever customer, industry or company you’re working with. Methodologies, templates and processes get tweaked, but the fundamentals are usually about the same….organization, timely reactions, ownership, honesty, stubbornness, willingness to lead, etc. Those things remain the same – and continue to drive me down the right path to this day.

Well, that’s my story…were it not for an ill-conceived route through college starting with chemistry classes and ending with system design classes and a good mentoring manager as my first supervisor, I may not be here, but I’m glad I am.

Tell us your story…

The Requirements Frustration Factor

I’ve written a lot about requirements and how critical they are to getting a project off the ground and headed in the right direction. In the long run on a project good requirements are important for the following reasons and more:

• Keeping the project aligned with original goals
• Keeping the project on time
• Keeping the project on budget
• Scope management
• Customer satisfaction
• Ease of development and minimizing re-work

When I’ve discussed requirements up to this point I’ve usually been referring to them in terms of larger engagements with formal, external customers. When you’re dealing with a cut and dried contract with an external customer, you have a SOW to work against, a set budget and change management is critical as is customer satisfaction, so therefore requirements and scope management are critical as well.

Internal Fiasco

So, what happens when you get an add-on internal project for an influential person within the organization and the requirements are somewhat grey? I had a project like this not very long ago. I was asked to run a project with the basic direction of ‘just do it’ along with my other projects and ‘make them happy.’ Fun!

When one of these falls in your lap, you can try to formalize things as much as possible and wrap good project management practices around it, but if the customer (in this case, internal customer) is not interested or willing to participate and at that point considers it frivolous attention to too much detail, what do you do? That’s the quandary…because I can tell you what happens if you don’t do enough.

I thought I was getting my hands around it… I met with the customer on requirements, documented them at the most detailed level I could since I was only working with the information I was able to drag out of them. They were basically ‘approved’ as I had documented and communicated them.

The bad news is that three months later at the completion of this small one-off process improvement project, one area was lacking the proper detail that this customer now wanted. (Notice I’m not going into too much detail here – it would not be in anyone’s best interest nor is it important for the point I’m trying to make.) Forget that fact that I had asked about this particular area of the requirements on two separate occasions and confirmed that we were like-minded…at least as far as I could tell with the minimal involvement the customer wanted to take at that time.

Of course, in the end the only real solution is to fix the issue and move on, which is what I did. But I’m looking back and trying to figure out how I could have avoided that train wreck with some different corrective action during the requirements definition period. Since it’s an important, visible, and powerful internal customer, playing the blame game really does no good…it’s still all about customer satisfaction no matter who’s right.

Lessons Learned

If this were to occur in the future, and I was still unable to gain the proper involvement from the actual customer, I would likely request that they appoint an individual to work directly with me in detail on documenting and finalizing the exact requirements. That is my lessons learned from this situation. That way, the internal customer truly has better representation in the process because they will assign a dedicated individual whose job will be to ensure accuracy on the customer side. Whereas, in the situation I was involved with I had that responsibility as well as the delivery responsibility and the end result needed re-work before it fully met what the customer wanted.

Unfortunately, I unwittingly walked into one of those “I’ll know it when I see it” type customer situations that we all want to avoid. I find that those are much easier to avoid when the customer is external and knows up front that they are paying extra for everything not documented as a requirement.