Login access is only available to associates and administrative staff.

Stakeholder Mapping Explained

  • By: pcadmin on 07 Feb 2015

Procept associate Kevin Aguanno is delivering a webinar titled "Stakeholder Mapping Explained" which will teach participants how to build and use a stakeholder map to help understand a project's stakeholders, their interrelationships, and the "office politics" that affect their priorities and decisions. This advanced technique is suited to project and program managers as well as business analysts. The webinar will be held on April 17, 2015 at Noon Eastern (Toronto) time. PMPs will earn 1 PDU and CBAPs will earn 1 CEU for attending this event. There is a nominal fee to participate in this 60-minute webinar and just for visiting the Procept web site, you can get get 50% off (and pay only $5) by using discount code 17APRWEBINAR when registering — just another reason why Procept clients keep returning time and time again.

Process Change Management - Step 1

  • By: Sarah Eisan on 19 Nov 2014

This week’s blog is the beginning of a 3 part series on Process Change Management. The first part of this series will discuss the first step of current process evaluation and preparation for the next step.

Step 1 – Evaluation and Preparation

The first step is to understand the current process.  When I say understand the process I don’t mean simply understanding the process to the point of being able to draw a diagram of it (I say that because I’ve seen this mistake many times) I mean truly understanding it on 5 levels

Level 1 – What

What is the process? What are the inputs and outputs of each step? This level should provide enough information to build a high level diagram of the process to work from.

Level 2 – Who

Who is directly and indirectly involved in the input, action and output of each process step. It’s important to talk to these people about what works well and not so well from their perspective. This is important for 2 reasons; the people involved in the process often have a unique perspective about what works well and what can be improved upon and secondly, this is an excellent opportunity to start putting the idea of change in their minds and to start dropping seeds of “what’s in it for them” – the benefit of this will become more apparent in later steps.

Level 3 – When

When does each step take place? What steps are time sensitive? How long should each step take?

Level 4 – Where

Where does each step take place? Does the step occur in a physical or virtual location?

Level 5 – Why

Why, this question should be asked of all of the above levels. For example, why is the process done this way? Why are the sales staff involved? Why does invoicing occur before shipping? Why does order picking take so long? Why do orders need to drop by noon? And then when you get answers, ask why again.

After completing these steps, document the results. It’s a good idea to prepare various forms of documentation such as written descriptions and diagrams. These documents will be used to confirm understanding between the project team and the customers.

In preparation for the next step, the documents will be used to confirm if your understanding of the current process is correct and to identify what revisions may be required. Once this is confirmed and accurate, expectations need to be identified, discussed and agreed upon. This process make take a few facilitated sessions to complete, it is well worth the time it will take and will be very helpful to have documented and agreed upon before moving to the next step.

In summary, it is essential to have this in-depth understanding of the existing process before attempting to undertake any changes.  Many times I’ve seen BA’s who say they understand the process and can show a very pretty Visio diagram of the process but later on in the project it quickly becomes apparent, that there understanding is only superficial.

To be continued…

The Question of Project Schedules and Liquidated Damages…

  • By: Sarah Eisan on 12 Nov 2014

This question was recently asked by a client after the baseline project schedule was submitted and approved…

“Can we show the actual start date of two activities before the contract award date?  The reason we would like to do this is that some of the work (manufacturing of cranes), was started before the contract was awarded and we have very high liquidated damages for each major milestone.  Please let us know if it is correct to show the actual start date of the two activities before the contract award date”.

Before I share my thoughts on this, stop and think for a moment on how you would answer this question…

Now, let’s look at a few key points:

  • First off, it is important to remind ourselves that liquidated damages are intended to compensate the client for costs incurred as the result of a delay.
  • The bid schedule showed a particular date of delivery and the client had accepted that date.
  • Presumably, the damages are only incurred after that accepted date.
  • Liquidated damages are NOT another word for “penalty” and apply to the contractual schedule (or notice to proceed, but that depends on what the contract and the notice to proceed said).

 

Given the above points, I would only show the dates if the client agreed that liquidated damage’s apply to the original contractual schedule rather than the accelerated date, and I would get that in writing.

Presumably if an accelerated completion date is so important, the client should be mature enough to appreciate efforts to mitigate schedule risk, rather than play games with the schedule and liquidated damages. I would hope that there is even a possibility to beat that original contractual deadline.

I have told clients in the past, that their managers would be more pleased if they deliver early, than if they set an aggressive date then have to make excuses (and find someone to place blame the blame on, usually the contractor) about being late.

They can throw around blame all day, and apply all the liquidated damages in the world, but at the end of the day they still have to stand up in front of their management or client and explain why they are late and have all the associated uncomfortable and time wasting arguments, discussions, and claims as to whose fault the delay was.

What would you have said to the client and why?

Modeling Techniques and State Diagrams…

  • By: Sarah Eisan on 05 Nov 2014

If you have been attending the IIBA’s Building Business Capabilities Conference this week or just following the excitement on Twitter like I have (search #BBCcon), you have probably noticed that there has been a lot of discussion about modeling.  For instance Elizabeth Larson gave a presentation on the Top Models for Complete Requirements Analysis and Francine Wolfe gave a presentation on What’s a State Model.

In my daily work as a business analyst, I’ve employed many modeling techniques however State Models (or Diagrams), is one that I’m less familiar with; this has motivated me to learn more about this technique.

As always, when familiarizing myself with a new Business Analysis technique, my first stop is the IIBA’s BABOK V2. The BABOK describes State Modeling as “a diagram that specifies a sequence of states that an object goes through during its lifetime and defines which events cause a transition between those states. The allowable behavior of the object is dependent on its current state.”

See below for an example of a State Model from the BABOK V2:

 

 

Advantages to using State Models are:

  • They can help to uncover missing data and requirements
  • They may help clarify confusing or conflicting requirements
  • They provide a visual diagram or picture of what could otherwise be a complicated written description or list
  • They can help identify missing processes

When using State Models, be aware that it is sometimes easy to include states that are not relevant, thus unintentionally expanding the project scope. Another point to be aware of is that the various states might have their own unique data associated with them, which you need to be aware of and document.

State Models can be particularly helpful to determine the life cycles such as the life cycle of a customer interaction, determining the impact of an event such as the reach of a marketing campaign or to determine impact how a programing change can affect an application.

Now that I’ve became more familiar with State Models, I will definitely be incorporating this tool into my go to ‘BA Tool Box’.

How have you incorporated State Models into your business analysis activities?  Please share your examples and their outcomes!

Critical Skills for Scheduling and Planning

  • By: Sarah Eisan on 29 Oct 2014

Recently there was a post on a discussion board asking what 12 to 15 critical skills are needed to be an effective Scheduler/Planner and how someone should approach the acquisition of these skills.

Surprisingly, many of the comments highlighted computer skills and software knowledge in the top 3.  While those are always useful skills to have, I wouldn’t consider these to be ‘critical’ skills for a Scheduler/Planner role. It is more important for a good Scheduler/Planner to have a solid understanding of the theory of developing a schedule and have the ability to connect it to a computer modeling simulation tool.

To expand on this point, the Scheduler/Planner should be able to translate what happens on the job into mathematical relationships that can be quantified, evaluated and measured.  If they cannot do this, and are relying on strong computer skills and software knowledge, they will not be successful.

Learning a new software application such as Microsoft Project, is typically acquired during 1 or 2 weeks of a training course where as learning how to model the actual job in the given software and then interpret the results takes many other skills such as:

  1. Practice and experience
  2. Communication skills
  3. Effective active listening
  4. Asking questions (and knowing what questions to ask)
  5. An understanding of the project environment
  6. An understanding of the organizational culture
  7. The theory of float and how to use it
  8. The building in of and managing contingency
  9. An understanding of critical chain and how to apply it
  10. How to track progress
  11. How to measure earned value
  12. An understanding of project management

When accessing a candidate’s suitability for a Scheduler/Planner position, testing on the above skills will provide a better assessment of how well they will perform on the job as opposed to testing their software knowledge and computer skills.

As for approaching the acquisition of these skills, it is always good to get an accurate assessment of where you’re currently stand with the critical skills, conduct a gap analysis between where you are and where you need to be and then use the results to determine what areas of focus will provide you the greatest return on investment.  In additional to this approach, I’ve always found it beneficial to find a mentor in the field that you are looking to move into and work with this person to help prepare you for your future career.

Do you agree that the skills specified here are more important for the Scheduler/Planner role than software knowledge and computer skills?  I’d love to hear your thoughts either way!

All About Use Cases

  • By: Sarah Eisan on 22 Oct 2014

What are uses cases? Wikipedia defines use cases as a list of steps, typically defining interactions between a role/actor and a system, to achieve a goal. The actor can be a human, an external system, or time. Often a use case is presented as a diagram to depict these interactions as a means to identify, clarify and organize requirements.

A use case can have several elements with the most common being:

  • Actor – anyone or anything that performs a behavior or action
  • Stakeholder – someone or something with vested interests in the behavior or action
  • Primary Actor – stakeholder who initiates an interaction to achieve a goal
  • Preconditions – something that must be true or occur before the use case can happen
  • Triggers – an event that causes the use case to begin
  • Main success scenarios – basic use case flow where all conditions are ideal and nothing unexpected occurs
  • Alternate paths– alternate flows where there is a deviation from the basic flow; these paths are when something unexpected occurs and several of these alternate paths can be identified for each basic flow

There are several reasons to incorporate use cases into your project, such as:

  • Improving communication among team members
  • Encourage common agreement about requirements between the business and the development teams, who are often speaking different ‘languages’
  • Identifying process alternatives, process exceptions and outstanding issues
  • Identifying out of scope items
  • Automation of manual processes
  • Assisting developers to understand business processes
  • Aiding in the recognize of patterns and contexts in functional requirements
  • Prioritization of development work
  • Assisting testers to identify gaps between the requirements and what has been delivered

While use cases have many benefits, there are also a few limitations to be aware of:

  • They are not ideal for capturing requirements in non-interaction based situations
  • Skilled writers are required to write quality use cases
  • Depending on the complexity of the situation, this technique may not be the most appropriate to use
  • They should not be used as a standalone technique to communicate requirements

To write a quality use case, it is imperative to write the use cases in language that is easy to understand by both the business and development teams.  Guidelines to follow when writing use cases are:

  1. Identify who the users will be
  2. Pick the first user to start with
  3. Define what the user will want to do or what their goals are
  4. Determine what the basic path will be for each goal
  5. Document each step that will be required to accomplish each of the users goals
  6. When documenting each step, describe the steps in terms of what the user does and what the expected result or response should be
  7. When the basic path is described, consider alternate situations and add those to alternate flows of the use case.
  8. Look for similarities in the use cases and any that may be related, and note the relationship

Here is a simplistic example of a use case diagram, compliments of Wikipedia:

 

 

Do you use use cases on your projects?  If so, what are the benefits and limitations you have found?

Challenges of Project Financial Audits

  • By: Sarah Eisan on 15 Oct 2014

I recently had a conversation with a colleague regarding an article she read about an accounting firm that ran into difficulties while investigating a project-based organization and a few thoughts came from that conversation… Sometimes, even when all the right things are done with regards to accounting for project financials at the organizational level (for example Project Managers regularly reporting on cash flow in accordance to the organization’s accounting system), projects can still spin out of control. Why does this happen? 

One common issue is that the accounting systems are often not based on project deliverables; then you also have projects that are being fast tracked and low bid wins… and if any of these issues occur in conjunction with each other, it can be a perfect storm.  

The project manager has little control over these issues since they are decisions that are made by the executive level and tied to poor governance. These types of situations require analysis from two perspectives: an accounting audit with a top-down perspective and a Project Management type organization, with a bottom up perspective. The blame for projects failing in these situations cannot simply be placed on the last person standing (the Project Manager that can be called “the executioner”). Placing the blame there is too simple of a solution and will perpetuate a cycle of hiring poorly-performing Project Managers; good Project Managers will not want to work for an organization with a reputation for this practice.

Think about a situation where the blame is placed on the Project Manager… they will begin managing projects by following all the “rules” in the best interest of their job security as opposed to what is in the best interest of the project; a rippling effect of this will then be Project Managers hiding bad news from leadership until it’s too late.

One wise executive of a very successful multi-national construction company once told my colleague that they do not fire Project Managers for poorly performing projects, they fire Project Mangers for not escalating problems and issues soon enough to try and solve the project problems… How does your organization handle these situations?

Who Owns Requirements: the Project Manager or Business Analyst?

  • By: Sarah Eisan on 07 Oct 2014

The quality of the requirements elicited can make or break any project.  Once thought to be the sole responsibility of the business analyst, requirements are now of great importance to the project manager as well.

With the continued expansion of the Collect Requirements section in the PMBOK Guide®– 5th edition, project managers are becoming more involved in and placing greater importance on the elicitation and quality of requirements.

There has been ongoing discussion in both the business analyst and project management communities regarding who should be responsible for the collection of requirements; I came across this table at http://www.batimes.com/articles/the-project-manager-vs.-the-business-analyst.html that does a great job at comparing the PMBOK tasks to the BABOK tasks and shows how the project managers role and the business analysts role, align with and compliment each other.

PMBOK® Task BABOK® Task
4.2 Develop Project Management Plan 2.3 Plan Business Analysis Activities
2.5 Plan Requirements Management
2.6 Manage Business Analysis Performance
4.4 Monitor and Control Project Work 2.6 Manage Business Analysis Performance
5.1 Plan Scope Management
5.2 Collect Requirements
2.5 Plan Requirements Management Process
3.1-4 Elicitation: Prepare, Conduct, Document, Confirm
4.2 Manage Requirements Traceability
4.4.5.1 Requirements Documentation
5.3 Define Scope 5.4 Define Solution Scope
5.4 Create WBS
5.6 Control Scope
4.1 Manage Solution Scope
5.4 Define Solution Scope
5.5 Validate Scope 7.5 Validate Solution
8.3 Quality Control (Testing-monitoring and recording results) 7.6 Evaluate Solution Performance(Results analysis and recommendation)
13.1 Identify Stakeholders 2.2 Conduct Stakeholder Analysis
10.1 Plan Communications Management 2.4 Plan Business Analysis Communication
10.2 Manage Communications
10.3 Control Communications
4.5 Communicate Requirements
2.6 Manage Business Analysis Performance

When you first read in the PMBOK that project managers have the task of collecting requirements, it sounds as if they should now be responsible for collecting the requirements; upon further review it becomes apparent that the Project Manager is rather responsible to ensure the activities for collecting requirements are covered in the project management activities and monitored as part of the project, with business analyst maintaining responsibility to execute the task of collecting or eliciting requirements and keeping the project manager apprised of the progress and any roadblocks encountered.

In summary, the business analyst and the project manager both play important roles on projects for a lot of the same activities; the combination of a strong project manager and a strong business analyst who can collaborate and work well together will be the foundation for success in any project.

Using Project Management Superpowers for Super Good

  • By: Sarah Eisan on 01 Oct 2014

Earlier this week I came across the Project Management Institutes Educational Foundation page that had a link to inspiring stories about people using project management education for social good.  If you’ve never visited this page, I would strongly encourage you to check it out http://pmief.org/get-inspired/stories-collection.

The first story I read was that of Reggie Brown, a PMP who moved to South Africa several years ago and began teaching project management skills as life skills to youth in some of the poorest towns.  He found that teaching project planning as a life skill helped students to achieve better outcomes from their decisions and increased their self-esteem; this enabled the students to be empowered to rise to the challenges of their circumstances.

While reading this, I began to think about how we as project managers can use our skills and knowledge to help others and what those skills could be. While this is a dramatic example of someone who moved to the other side of the world to help others, there are many ways we can help to teach and empower others with project management skills at home in our own communities.

In my opinion, the top 5 project management skills to teach others for empower would be:

  1. Understanding the roles and responsibilities of the project team and stakeholders – when making a decision or change, learning how to identify who impacted, determining what their role is and what their impact will be.
  2. Identifying project risks and impacts – learning how to identify the risks of making a decision or not making a decision, the magnitude of the risk and what the probability is of it occurring.
  3. Project planning, dependencies and scheduling – learning how to plan for a change, project or decision while taking in consideration for how it will be implemented, in what order tasks must be completed, how must complete them and when can they be completed.
  4. Project communication – learning to identify who needs to be communicated with, what means to use to communicate with them, how often to communicate and what information should be communicated.
  5. Project quality – understanding how to determine quality, what quality level is optimal and how to measure quality.

 

Some of the many community organizations that could benefit from learning project management skills or having access to a project management professional such as yourself are:

  • Local SPCA
  • Local food banks
  • Community health boards
  • 4-H Chapter
  • Shelters
  • Junior Achievement groups
  • Youth groups

 

Have you used your project management skills for social good or know someone who has? I’d love to hear your stories.

What the Heck is a Business Analyst?

  • By: Sarah Eisan on 24 Sep 2014

You’re meeting someone new for the first time and they ask “What do you do for work”?  You reply “I’m a Business Analyst”, most people will instantly have their look of curiosity replaced with a blank stare and you can already anticipate the next question…”What the heck is a Business Analyst”?

Over the years I’ve tried many explanations from text book definitions of business analysis to analogies to examples and one thing remains the same – it’s never a simple answer and it changes depending on where I’m working as a Business Analyst and what the scope of my work is at that time.

The IIBA categorizes business analysis work into 7 knowledge areas; Business Analysis Planning and Monitoring, Requirements Management and Communication, Elicitation, Requirements Analysis, Solution Assessment and Validation, Enterprise Analysis and Underlying Competencies.

Regardless of what work a Business Analyst is doing, they will typically act as a liaison between the business units in an organization and the technology specialists and/or technology functions; because of this, the Business Analyst role is often aligned with either the business unit (e.g. Customer Service, Manufacturing, Logistics), IT where they focus on both business and system aspects of a project or in a business analysis center of excellence where Business Analysts are grouped together with their peers to maintain consistency and continuous improvement.

Ultimately the goal of business analysis is to:

  • Create solutions
  • Give enough tools for robust project management
  • Improve efficiency and reduce waste
  • Provide essential documentation, like requirements document, project initiation documents and others

There are a variety of tools and techniques a Business Analyst will employ to achieve these goals but that’s a discussion for another day…

How do you answer the question of what is a Business Analyst?

Pages

Upcoming events

Latest Tweets

Sorry, twitter is currently unavailable.