Login access is only available to associates and administrative staff.

Free PM Training - International PM Day (Nov 5, 2015)

  • By: pcadmin on 16 Mar 2015

To celebrate International Project Management Day (Nov. 5, 2015), Procept Associates Ltd. is going to host a free day-long event in Toronto, Ontario where people can attend a series of 90-minute presentations on project management-related topics and earn free PDUs. Similar to the Professional Development Days held by many PMI chapters, this event will allow participants to learn from some of the best project management trainers in North America, while earning 8 PDUs at no cost to the participant.  A small $20 booking fee will be charged at the time of registration that will be refunded in cash at the door the day of the event. This booking fee has been put in place to reduce the number of people booking but not showing up for the event.

International PM Day is an international movement started in 2004 by Frank Saladis, a U.S.-based project management trainer, consultant, and author. The goal of the movement is to recognize the efforts of project managers who are striving daily to improve people's lives.

New Video: Defined vs. Empirical Management Explained

  • By: pcadmin on 09 Mar 2015

Procept has just released a short video of Kevin Aguanno, one of Procept's Senior Consultants, explaining the difference between defined and empirical management methods.  This is the latest in a series of short instructional videos that Procept will be releasing for free on YouTube to highlight the teaching skills of its instructors and to drive interest in Procept's offerings. Subscribe to the Procept YouTube channel to get notified of new videos as they are released.

Procept Launches New Online Risk Management Course

  • By: pcadmin on 04 Mar 2015

Procept Associates Ltd. is pleased to announce the launch of a new online self-directed e-learning course titled "Introduction to Risk Management." This new course includes nearly three hours of video, a 50-page workbook, and an online test at the completion of the e-course.

Darya DumaThe e-course is based on a video recording of a classroom session hosted by Senior Consultant Darya Duma, Procept's Project Management Practice Lead and a member of Procept's Management Advisory Board. The course is hosted by Procept's strategic partner, GenXus Corporation on its e-learning portal (http://learn.genxus.com) and is available for licensing to our corporate and university clients.

For more information, contact sales@procept.com.

 

22nd Edition of "Farndale's PMP and CAPM Preparation Guide" Now Available

  • By: pcadmin on 09 Feb 2015

Now in its 21st year in print, Procept's popular Farndale's PMP and CAPM Preparation Guide has been recently updated and has just been released in its 22nd edition.

This book describes the PMP and CAPM examinations and suggests a study process. The 250+ question practice exam is organized according to the knowledge areas of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 5th Edition. Countless exam writers have verified that these practice questions are similar to those used in the actual PMP exam. This guide has helped prepare more Canadians for the PMP exam than any other sample test.

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?

Pages

Upcoming events

Latest Tweets

Sorry, twitter is currently unavailable.