Tag: Learning

5 Project communication mistakes.

Business analysts can get so lost in the details of the projects that we forget to tell the people who are most affected.

Or, we try to tell them but they don’t quite understand. Or we just talk to senior stakeholders and ignore the rest. 

Here are five ways communications can go wrong.

1. Treating communications like a luxury

The change manager – or dedicated communications officer on big programmes – is often the first to be cut, if indeed the investment has been made in hiring one to start with. The logic here is that running a good communications operation is secondary to delivery activities and, in one memorable case, I’ve heard clients refer to such roles as ‘walking headcount’, meaning their days are numbered.
However, as many teams quickly find out, there is very little on a project that does not fall within a communications officer’s remit: obvious work such as keeping end users informed of a project’s progress and probable impact but also vital but more subtle work like managing different types of stakeholder, creating alignment in messaging, getting buy-in and support. Without this, most BAs managers quickly find themselves sinking and having to dedicate much of their time to this work – taking it away from ‘delivery’. 

2. Failing to manage tricky customers effectively

As every contractor, consultant or internal BA knows, stakeholders can be a difficult crowd. Personalities vary, irrespective of seniority: one likes detail and weekly updates, one just wants the headlines and a quarterly steer co; another refuses to read emails but claims to have not been informed; others vie for political advantage over their colleagues at the expense of all other agendas.
Ineffective strategies for dealing with these situations include ignoring difference, trying to pander to everyone or taking the situation personally rather than seeing it as a communications challenge. Through this lens, all inter-personal friction can be mitigated and every stakeholder can be managed; indeed, the only failure is to give up and stop trying new approaches.


3. Creating an information vacuum, allowing gossip 

Many projects become their own worlds, often seeing the multitudes of stakeholders who will ultimately be affected by the project’s outcome as an afterthought. Well, people talk and a lack of information will be addressed through gossip. Before you know it, stakeholders will believe your project has nefarious goals or – perhaps worse – that you are going to make all of the organisation’s problems go away.
Clear communications are the only way to manage this, ideally presented by a client stakeholder with good rapport with the affected groups. 

4. Being boring

We go to work and – for whatever reason – we think everyone else suddenly wants to be bored out of their minds. So we fill our emails with tired jargon or we inflict long PowerPoint presentations on our colleagues or we feign enthusiasm in the hope our project team will feel motivated. But, our brains in the office are the same as they are outside the office: same attention span, same interests, same intelligence. Not using this fact and communicating in a similar way to how we are accustomed outside the office is a mistake that is sure to see your message being lost or ignored.
Business analysts are particularly culpable. Sometimes, we manage to be both dull and over-bearing to our stakeholders – or try to inject ‘fun’ that numbs the mind of on-lookers. The best approach here tends to be to deliver simple messages, ideally with no more than one or two slides in support. With so many free third party tools available, many of us could also consider playing with well-formatted html emails, infographics, video presentations; but it is rare such media replace the strength of a solid and impactful presentation. 

5. Being slow

Many projects that do have a dedicated change officer responsible for communications spend a long time devising a strategy, defining which communications go to which people at which times. This is useful in principle but often they are encumbered by having to get approval for the plan – or individual communications – from unavailable stakeholders or of over-ambitious and costly strategies that end up either never being implemented or rushed at the last minute. Communications are, by their nature, newsworthy – and news must be delivered while it is still new.
Business analysts on projects of all sizes need fixes for these issues to allow them to focus more on the day-to-day running of their projects. If you want to explore ways to address these issues and manage your communications allowing more time for higher-value project activities, please feel free to reach out to the writer of this article.

Top 3 Activities for a Business Analyst in a Discovery Phase

In at the deep end

So, you’ve just heard you’re going to be the Business Analyst on an Agile team that’s going in to a Discovery and it’s your first one.
For my first Discovery, it was daunting let me tell you. I already knew quite a few tools and techniques a BA should use during the lifecycle of a project, but what ones do I use that are particular to a Discovery phase?
For this blog, I interviewed other Business Analysts, Scrum Masters, Product Owners and Developers to get their view on what the role of the BA is in Discovery and I will use their opinions (along with mine) to provide what I think are the top 3 tasks a BA should carry out.

Time is of the essence

You may be thinking, ‘surely you just apply the right tool or technique for the situation?’ Good question and I would say this is true. However. Unlike a traditional project where the BA would investigate, analyse and document literally everything, in Agile, Discovery phases are given quite a short amount of time before moving to Alpha and this is where as a BA (along with the rest of the team), you need to use your time wisely as you just won’t have the time to do all those ‘traditional’ BA activities.

Now, there is a process to follow in that you can’t start to create a backlog until you know what the user and business needs are, and you can’t find out those needs until you identify your users and stakeholders. So, this is where we’ll start.

Stakeholders: Don’t just identify, analyse

The top activity the other roles identified as a key role of the BA was to understand and define the problem. However, before we get to that stage, we need to identify our stakeholders and users. And perhaps more importantly, understand the stakeholder’s interest and their influence in your project.

For me, this is a critical exercise that I don’t feel is given the importance it should at the start of a project. They either get done and are left static throughout the project or not done at all.

While the BA might lead on this activity, it’s most definitely an exercise the whole team need to be part of. My tip here is to put a stakeholder interest/influence matrix on the team wall (hopefully you have one, if not, get some whiteboards!) and give yourself and the team a couple of hours for the session. There are plenty of templates online you can use or if not, just draw it on some flipchart. Give the team around 10-15 minutes to identify who they think are stakeholders and begin to plot them on the matrix.

There may be some conflict where these people sit on the matrix but as long as you agree on who are the highly influential or clearly fit in to a category, the borderline ones you can leave for now.

In terms of analysis and potential time constraints you have, don’t go in to any particular detail and spend time creating stakeholder wheels or stakeholder management plans, the interest/influence grid is sufficient. In addition, use the matrix to create your communication strategy to define what methods you will use to show progress of the Discovery to stakeholders and how often you will communicate with them.

For identifying users, this will be something the User Researcher will lead on as they will be interviewing them but you as the BA should be involved in those sessions. After all, if you are going to be writing the user stories based on their needs, you need to get this first hand. You will also pick up good interview techniques from the UR.

Framing the problem to define scope

Ok, so we now have a list of stakeholders and users and it’s time to start engaging them. Before you start looking at things like defining ‘as is’ processes, pain points and setting up interviews with stakeholders to get this information, you need to have an understanding of what the actual problem is the team has been put together to fix.

You may have been given a mandate as to what the issues are but until you engage the people ‘at the coal face’, they are just perceived issues. The quickest way to get to the root causes is to get those key stakeholders in a workshop and identify the following:

• Why are we doing this work?
• Who are our users, clients and stakeholders?
• What outcomes might users get from this?
• What outcomes might the organisation get from this?
• What are our key metrics?

Now, a lot of information will come out of this session and I see the key role of the BA is to deconstruct all these thoughts and views and turn it into something meaningful……like a problem and a product vision statement.

These statements are short and provide an overview of the vision, problems and methods the team will use to address them. It should be no more than a few sentences which is a difficult task and one I suggest should be collaborated and created with the rest of the team.

Once you are all happy with it, you need to share it with the stakeholders. Not to get agreement or for endless reviews, but to ensure everyone is on board with what the team are trying to achieve.

As some (maybe most) stakeholders may not be aware what a problem and vision statement is, you may have to spend some time explaining its purpose to them. Point out it’s not a personal view, but a collective interpretation of perceived issues that need addressing.

The backlog

As with defining scope, starting a backlog of user stories is not solely the responsibility of the Business Analyst but is something the team are responsible for and should contribute to. That said, the BA does play a critical role in the creation of a backlog. And that is to ensure that what goes in to it is of an acceptable standard. After all, rubbish in, rubbish out right?

I’ve seen this so many times whether it be on a new product or one that has progressed in to Alpha and Beta where the backlog has become a bit of a dumping ground for every idea, whim or ‘wouldn’t it be good if’ thought.

For a start, everything in the backlog should either be related to a user need or part of the product roadmap. If it doesn’t, it shouldn’t be there. If someone does have an idea worth further exploration, put it on the user research/UX hypothesis board so they can establish whether there is an actual need for it.

Before you start creating a backlog, get the team together to agree ground rules. I suggest you hold a user story writing workshop with the team where you can begin outlining the backlog. This ensures the team are involved from the start and you can agree principles with them to stay clear of the ‘bloated backlog’.

Who might I be working with in a Discovery team?

Discovery teams can be made up of several roles, most commonly; a Product Owner, User Researcher, Business Analyst(s), Subject Matter Experts (SMEs) and a Scrum Master/Delivery Manager

I’ve worked on Discoveries where a Scrum Master/Delivery Manager wasn’t part of the initial team and I found the focus and cohesion of the team became lost at times due to a lack of discipline in setting and achieving targets (i.e. sprint planning). When time is the key factor, the team needs to stay focused on its goals which I think the Scrum Master brings.

You’ll start to get the impression now that the Business Analyst is not really ‘solely’ responsible for the outputs of a Discovery but is involved in all of them. One of the people I interviewed for this blog explained his view of the role of the BA in a great way. He said they are ‘decoders’. By this he meant they translate all the information gathered (and there will be a lot of it) in to outputs that not only the team understand, but any stakeholders.

I believe this is the primary role of the BA however in an Agile Discovery, you should be able to evaluate what you are doing is of value and that you’re not just ‘going through the motions’ because of pre-defined duties of the Business Analyst.

I hope this has been helpful and that if you are asked to join a Discovery team, you are equipped to get engaged in those top key deliverables to make the Discovery a success.

5 Myths About PMI’s Business Analysis Certification

In this article I aim to debunk some of the misinformation I often hear surrounding PMI’s Professional in Business Analysis (PMI-PBA) certification in hopes of providing better clarity to support improved decision making.

Background: The PMI-PBA certification hit the market in late 2014. It’s not quite three years since its launch, but it is doing well; having now attained credential holders in 82 countries. The idea that PMI was developing products in the business analysis space was shocking to some, but PMI has been recognizing the importance that requirements play in achieving program and project objectives for years. For those who are familiar with “A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition” (PMI, 2017), it’s no surprise to hear that successful projects require the effective use of business analysis. It makes complete sense why PMI would be investing heavily to raise awareness about the relationship between mature business analysis practices and organizational performance. In “Business Analysis Leading Organizations to Better Outcomes” (2017), PMI reported that organizations with high business analysis maturity, demonstrate above average performance across all key organizational success metrics—including:

  • Financial performance (69% versus 45%),
  • Strategy implementation (66% versus 21%),
  • Organizational agility (40% versus 14%), and
  • Management of individual projects (62% versus 29%).

So there should be no question on why PMI cares about business analysis and has set out to develop a top-notch professional credential to help organizations improve their capabilities to deliver on their strategic objectives.

Despite approaching its 3-year anniversary, there is still confusion about what the PMI-PBA is all about. As with many new products, there are early adopters and there are those that take a wait and see approach; certification is no different. For those who adopt later – there may be weeks or months spent researching, discussing, or listening to others share their experience and knowledge. This is the time where there should be sufficient and accurate information to base discussions and decisions on; and there is – on PMI.org! Unfortunately, (as I have found firsthand) there are some postings, presentations, and conversations on social media that are perpetuating a misunderstanding about the scope, structure, and value of the PMI-PBA. I don’t believe it is being done on purpose or maliciously—I think it is a byproduct of the community misunderstanding PMI’s objectives and the product characteristics. I hopefully clarified PMIs objectives above—so let’s set the record straight on the PMI-PBA product.

5 PMI-PBA Myths

I have assembled a short-list of the top five misguided statements I have heard about the PMI-PBA. Hopefully this article provides you better information and helps to dispel the misinformation. If you are considering a PMI-PBA, hopefully this information helps you further your discussions with your manager and professional contacts. At the end of the day, the decision to pursue a PMI-PBA or not, is owned by those who must make the investment. Be wary of taking the advice of consultants and peer business analysts who convince you that a certification is right or wrong for you. Everyone needs to perform their own analysis, because each person’s situation is different. This article isn’t about convincing you one way or the other, it’s simply intended to provide you factual information to assist you in your decision making process.

Here we go…the top five myths about the PMI-PBA:


Myth #1: The PMI-PBA is an entry level credential.

This is absolutely false! You can debunk this misinformation by taking a look at the eligibility requirements in the PMI-PBA Handbook downloadable from PMI’s website. To be eligible to take the exam, you must demonstrate either 7,500 or 4,500 hours of business analysis work experience and 2000 hours of business analysis experience working on projects. The 7,500 or 4,500-hour requirement is determined based upon your educational background. Further details are listed in the PMI-PBA Handbook. These hours were not randomly selected. An extensive role delineation study was performed by an external third party and the results indicated that these were the hours required in order to demonstrate competency in business analysis. The PBA exam is also structured to include scenario-based questions which rely heavily on experience not book knowledge to answer. From my personal experience taking the exam, I can attest to the fact that the PMI-PBA is clearly developed for experienced professionals.

Myth #2: The certification confines business analysis to projects and programs.

Completely false! PMI research has shown that 83% of business analysis is performed on programs and projects in highly mature organizations, but this does not mean that PMI defined business analysis only to this context. You can debunk this misinformation by taking a look at PMI’s definition of the term portfolio which states it consists of “projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.” “The Standard for Portfolio Management Fourth Edition” (PMI, 2017) is more than managing projects; hence PMI’s business analysis standards do the same because business analysis is discussed in the context of how it is performed in support of portfolio, program, project management and operations. The “Business Analysis for Practitioners: A Practice Guide” (PMI, 2015) provides an entire chapter, Needs Assessment, that discusses pre-project business analysis activities. Later this year you can take hold of “The PMI Guide to Business Analysis” (PMI, 2017) which goes further than the practice guide in explaining how business analysis supports portfolio, programs, projects and operations. Keep in mind that how business analysis is defined is based on extensive research, not any one person’s idea of how it should be defined. 

Myth #3: The PMI-PBA was developed by a group of project managers.

No, sorry this is false too! I can see where some people might think this is the case, but PMI definitely used a team of experienced business analysis professionals from around the world and across industries to develop the PBA exam questions. PMI continues to do so too, because the test bank is refreshed on an ongoing basis. New exam writing initiatives ensure that the PMI-PBA exam questions remain relevant and reflect the latest thinking as presented in PMI’s standards and confirmed across the profession. Those assisting in writing new exam questions are just as experienced as the original development team. I think I should also mention that all PMI-PBA exam questions once written, are also reviewed by experienced business analysis professionals. Additionally, each exam question is required to be backed by at least two independent business analysis references. I don’t want to forget to mention that exam writing teams also have access to extensive PMI research. This credential is absolutely developed by business analysis professionals for business analysis professionals.

Myth #4: The certification is for project managers or PM/BA hybrids.

I can’t say this statement is completely false, because there are some PM/BA hybrids or project managers who qualify to sit for the PMI-PBA exam BUT not all project managers and not all PM/BA hybrids are eligible. In fact, not all business analysts are eligible! In my response to myth #1, I indicated the work experience requirements. It is these requirements that dictate eligibility, not your job title. Product owners, business analysts, project, program, portfolio managers, requirement managers, IT analysts and numerous other titles may be included because it’s not the job title that matters. What does matter is the number hours of ‘business analysis’ experience you possess. You demonstrate your experience on the PMI-PBA application. Therefore, if you are doing any of the work discussed in PMI’s business analysis standards, you are performing business analysis and may qualify to sit for the exam. It’s worth checking out the eligibility requirements to see if you qualify – regardless of your job title!

Myth #5: PMI has defined business analysis as a subservient role to project management.

Oh gosh no! I think it’s time we debunk this PM/BA subservient concept, it’s been around a long time and it’s not how we operate at all if we want to be successful. PMI research shows that highly mature organizations encourage high levels of collaboration between their portfolio, program, project management, and business analysis professionals (“Business Analysis: Leading Organizations to Better Outcomes” [PMI, 2017]). We are all part of the same team and we will jeopardize our success if we fail to collaborate. PMI has not defined business analysis as a subservient role. In fact, the “PMI Guide to Business Analysis” and “The Standard for Business Analysis” publishing this year will sit among some of PMI’s most prestigious standards” – the “PMBOK® Guide,” “The Standard for Portfolio Management” and “The Standard for Program Management.” Business analysis is no less important, but equally important for organizations and individuals to understand and embrace.

I hope my responses to the top 5 myths about the PMI-PBA helps to dispel some rumors, reduce confusion, and allows for improved decision making when it comes to researching a professional certification in business analysis. Remember, PMI may be the Project Management Institute, but this doesn’t mean PMI only serves project managers. It’s not practical to think this way. Those who have experience working on ‘successful’ change initiatives within their organizations can attest to the fact that it’s a collaborative effort. We can’t succeed by separating our business analysis professionals from our project management professionals! This is one of the reasons I am encouraged by the contributions PMI is making to the business analysis profession and even more encouraged to see that CIO.com recently ranked the PMI-PBA as the highest paying business analysis certification on their list.

Inspiration, Enthusiasm, and Triumph – The Journey to Becoming a Certified Business Analyst

They say a journey starts with a single step forward, but the reasons behind taking that first step can lead you down paths you never thought you would be able to walk upon.

This is the story of my journey into becoming a certified Business Analyst.

This whole journey didn’t start out with great fanfare. The reason behind why I chose to pursue the IIBA Certified Business Analysis Professional CBAP® certification was not actually a lofty one. It did not stem from a need to align myself with, at that time, the rapidly growing global network of professionals dedicated to raising the awareness of Business Analysis value through Business Analysis standardization and professional designation. Nor did it stem from a desire to authenticate my many years of Business Analysis and be recognized by the established Business Analysis standards association. The only reason I had initially for obtaining my certification was that I thought was doing a good friend a favor. But, by the time I sat for the CBAP® exam, my reasons had evolved!

It was the winter of 2008 in Minnesota when a dear and trusted fellow BA stuck his head into my cubicle at work and announced, “Hi, I am applying to sit for IIBA’s brand new CBAP® certification exam in June, and YOU are going to do it with me! We can study together!” Well, I thought to myself, it is winter here in Minnesota, after all, and there will not be much to do over the next 2-3 months.

“Okay,” I responded to my friend, “Let’s do it!”

So, my friend and I started our preparation for the CBAP® exam.

In 2008, the IIBA was all of 4 years old, but it had literally exploded from a start-up 37-member work group into an established association of over 5,000 members worldwide. There was a published Guide to the Business Analysis Body of Knowledge (BABOK Guide®), an implemented certification program and IIBA chapters were being established all over the world. In those four short years, there had arisen a groundswell of Business Analyst and industry support for the IIBA and everything that it stood for. This phenomenon was evidence of the high dedication and well-placed vision of the initial 37 members and of all those who joined their ranks in the next few years.

Our first step in preparing for our certification was to apply to sit for the exam. Sitting for the CBAP exam requires that applicants meet a specified number hours of BA work experience, with a minimum number of hours spread across a minimum number of the BABOK’s Knowledge Areas (KA). Being the dedicated BAs we were, we used a requirements management approach to filling out the exam application.

First, we broke down our resume’s work history into Business Analysis related tasks within projects, listing each project’s start and end dates. Using this chronology, we built two grids. One grid, cross-referenced our Business Analysis work history to each of the BABOK’s Knowledge Areas (KA,) where it applied, and the second grid calculated, by project, the net number of work hours spent on each BA task within each project.

These two grids made it very easy to calculate the total number of BA work hours and BA work hours by BABOK KA for the exam application. One huge advantage to building these two grids was that we had to survey each BABOK KA deeply enough to understand what each KA was about and understand where our work experience applied. Building these grids to fill out the exam application provided us with the perfect overview of the BABOK.

Once our applications for the exam were completed and submitted, we turned our attention to studying. The first thing we did was to set a realistic, but solid goal of 3 months to prepare for the exam. We quickly figured out that we could not memorize the entire BABOK in 3 month’s time, to the depth it would take to pass the exam. So, we needed a targeted approach to guide us through consuming all of the knowledge in the BABOK.

Today BAs are very fortunate to have so many and valuable resources available to them. There are certification prep classes offered by many training organizations, multiple study guides, practice exams available both online and through training organizations, and study groups hosted by local IIBA chapters. There are also virtual study groups, online blogs, online flashcards, etc. Searches online for ‘how to study for the CBAP’ bring up a plethora blog posts for your review. These blog posts are certified BAs mentoring fellow BAs and are a very valuable source of information for anyone wanting to sit for the exam.

In 2008, there were good resources available to assist with studying, albeit not as many as available today. After surveying all the available resources, we chose our strategy. We signed up immediately for a prep class through one of the training organizations. And we purchased practice exams and prep question flashcards from two different training organizations.

The prep class we took provided the perfect guide for consuming the vast amount of information in the BABOK and enabled us to pass the exam. The class took us through the tasks and activities within each BABOK KA and taught us the inputs (most important) and outputs of each activity. The class also took us through all the different types of modeling: usage, process, flow, data, and behavior models and showed us when to apply each one during Business Analysis. Lastly, the class pointed out important terms and definitions to memorize and gave us mnemonics to help memorize lists of Inputs/Tools/Techniques/Outputs (ITTO).

My friend and I formed our own 2-member study group, tossing practice test and flash card questions at each other throughout our workdays as often as possible, over our 3 months of study. The practice exams and the flashcards were also invaluable in helping us prepare for the wording of the questions on the exam. The exam questions go through multiple reviews before becoming exam questions, and they are designed to test subtle understanding. The questions are written to ensure that a BA can distinguish between what is correct and what is almost correct in a given situation. It takes practice to learn how to read and understand these types of questions correctly and to answer them accurately. The practice tests and flashcards taught us this critical skill.

Prior to 2008, I had not been highly involved with the local IIBA chapter. I periodically went to monthly chapter meetings and occasionally read their newsletter. I had been a Business Analyst for over 25 years and loved the work. But, my experience was that there was widely varied understanding of what the discipline of Business Analysis involved. The importance of Business Analysis was not consistently valued, and the role of a BA was often not as empowered on a project as it needed to be.

Shortly after delving into studying for the CBAP® exam, I discovered how much momentum and dedication was behind the IIBA organization and the solid value that IIBA was bringing to the Business Analysis discipline through standardization and credentialing. My reason for pursuing my CBAP® matured from merely doing a friend a favor into a sense of total pride for my profession and excitement over becoming part of this movement and obtaining my CBAP®. Today, I get excited over the growing list of certified names on IIBA’s Website and that IIBA now offers 4 established levels of certification in Business Analysis.

The journey can be rough, but very rewarding. In the end, Business Analysis certification was the most rewarding part of my career.

Letter from the Editor Ides of March and the Certification Quest

The Ides of March are coming. Officially marked on the Roman calendar as March 15th as the date Julius Caesar was assassinated in Rome and which put a rather definite end to his career.

If Emperor certification existed in ancient Rome, it might have saved him from that fatal sponsor meeting. The Emperor Book of Knowledge must have an entire chapter dedicated on how not to be stabbed in the Senate. Talk about sponsor management!

Certification is a relatively new thing in our existence. For many centuries the Master, Journeyman and Apprentice system was in use. Masters of the craft would teach Journeyman and Apprentices their craft working with each other side by side for many years. Eventually the Apprentice becomes the Journeyman and the Journeyman becomes the Master. Although we don’t use these terms today in business, you can certainly see these roles being played out. In the modern world, we take certification tests to prove our knowledge after we have an enough experience in the profession.

My certification journey started off when I was a director of project managers and I was meeting with the PMO director and CIO. In this meeting, we were talking about PMBOK 1.0 and how some of these concepts could be used within our organization to drive our projects more effectively. When the subject of certification came up, we passed on the idea. A few years later I’m in a similar meeting discussing PMBOK but in this meeting my leadership turned to me and said, “I think to make yourself more credible as a leader of Project Managers, you should get this certification”.

I was a leader of other Project Managers and good at my craft of Project Management. Being asked to prove my expertise to body of folks outside the organization was terrifying. What if I failed? Did that make me a “fake” project manager? Would my leadership and team really view me differently with a certification? It was clearly a situation where failure wasn’t an option. Failing the test in my mind would mean I failed at Project Management and that I shouldn’t be a manager. I had to ensure triumph and victory.

I spent the next 3 years studying and preparing. I did not take just one PMP Prep Course – I took several. I took Project Management training classes on all subjects. I grabbed a copy of the PMBOK and read every word over several times. I got the flashcards and simulated tests. I took that simulated test over a dozen times. Every question I got wrong went on a list. I analyzed that list and dug into the materials to find the correct answer. By the time, I was finished taking the simulated tests, I was getting only 1 or 2 questions wrong.

I gathered up my work history and all the projects I worked on over the years and spent an entire Monday putting it all together. I remember clicking the submit button on the application like it was yesterday. The next day I got the confirmation. I scheduled the exam at a local exam center in 2 weeks. After I got off the call, I started sweating. Am I ready? I mean REALLY ready to take this exam?

I build my brain dump paper of all the formulas and things that I thought I would need during the exam. Two pages of glorious detail memorized. I practiced making sure I could write it all out perfectly with in 10 minutes.

Two days before the exam, I stopped. No studying, no simulated tests, no practice – nothing. I stopped thinking about it cold turkey. I took the day off work telling everyone I was going on some personal errands – I just couldn’t get enough courage to admit I was going to take my certification test. On the day of the test I got in my car and drove to the testing site. I reviewed my brain dump paper and took a deep breath. “You just have to pass”, I kept telling myself, “70% is enough to pass. You’re not going to know it all. All you can do is your best.”

I walked in, signed in and probably got frisked for contraband but I don’t remember. I sat in front of relic of a computer, took a deep breath and was given the all clear to start. In less than 3 minutes my brain dump paper was completed. I was nervous and on hyper drive at that point. I then started the computer exam. I finished in one hour, then looked up at that clock and total panicked. Did I go too fast? Am I missing everything? I went through the test again worried I totally fouled it up. I changed a few questions which every prep class out there tells you is never a good idea but I did it anyway. Over and over I went through the questions until there was 15 minutes left. Should I spend more time?

I held the mouse pointer over the finish button for several minutes just staring at it. I just couldn’t click the button. This was the point of no return. I took a deep breath and clicked. A survey popped up. “How was your experience today?” it asked cheerfully. Now you want me to take a survey? I think in some small way I lost it. I just clicked all over the page to get rid of that survey. And then it happened. After a long pause that moment I feared and dreaded was upon me. The answer to all my efforts was on the screen.


I’m not sure but I probably floated out of that testing center. I know for certain I had a big smile on my face. It was spring and sunny out when I walked to my car. I got into my car and wore out the battery in my cell phone calling everyone I knew to tell them I passed. You couldn’t wipe that smile off my face for days.

Certification is life changing. It’s hard and requires a significant amount of time and dedication to complete. There is great reward in achieving this milestone and It has certainly helped my career many times over the years. Beware the Ides of March? Caesar didn’t make it out of his test but I certainly did.

This month’s featured articles are about certification. We hope you enjoy the great stories and journeys to get certification as told by real Project Managers and business Analysts. Don’t miss a single week’s issue!