Category Archives: Uncategorized

A Practical Approach to Risk Management


Following up on my last blog post regarding project management predictions for 2016, I thought I would expand on each of the ‘predictions’ in my first few posts of the year.

Projects Will Still Have Issues in 2016

As I noted in my post, projects will always have issues. And though we know this to be true, that shouldn’t prevent project managers and team members alike from being diligent in anticipating risks (that can become issues) and plan for them – as we have a responsibility to do so.

Now, while I’m confident I can regurgitate content from the PMBOK in terms of processes, inputs/outputs and tools & techniques related to risk management as good as anyone, for the purpose of this post I thought I would outline a few practical strategies from my own experience and perspective.

Do a Pre-Project Risk Assessment

Risk management seems to always be a topic of conversation within the realm of project management, but I would argue that it should pre-date the project kick-off. Before a project team is engaged and deemed to be accountable for the delivery of the project, the organization should have already performed an assessment of the project. Some of the points, questions and analysis to be considered might include the likes of:

  • How does this project align with our strategy?
  • Who is the customer? What industry are they in? Do we have any experience in this industry? Is doing work in this industry aligned with our strategy?
  • Have we done business with this customer before? If yes, what was our experience with them? If no, do we have any partners or contacts that have done business with them before and what was their experience with them?
  • Do we have team members with the skills required to do the work? Are these team members available at the allocation required to complete the work in the expected timeline and budget?

Build in Some Contingency

Based on the pre-project risk assessment, the organization should have a good sense of the level of risk a project has before it starts. If the project is deemed to be aligned to strategy and within the organization’s acceptable risk tolerance, the project team can use the outcomes of the pre-project risk assessment for inputs for the project risk planning.

For example, if we’re working in a new industry or with a new customer, or with a customer where there had been issues on previous projects, contingencies can be incorporated into the project budget and/or schedule (and other areas alike) to mitigate risks. This could mean having additional budget set aside for risks and/or additional time factored into the schedule. On the other hand, if we’re working with a familiar customer where we have a strong relationship and an established process proven to be effective with this customer, there should be less of a need for these types of contingencies.

Apply your Lessons Learned

Most project management methodologies advocate for a post project lessons learned (or post-mortem) type of session to identify project ‘failures’ and ‘successes’. From a risk management perspective, ensuring that lessons learned on past projects result in actionable improvements that are incorporated into future projects, is key.

Someone famous once defined insanity as ‘doing the same thing, but expecting a different result’, so unless you’re planning for the ‘insanity defense’ when your project goes off the rails, understanding and applying your lessons learned will be a key strategy in mitigating risks on your project.



Leave a comment

Filed under Management, Project Management, Strategy, Uncategorized

Project Management Predictions for 2016


You don’t have to look far this time of year if you’re looking for a view into what people are saying the next year will bring. As sure as there are those making resolutions for the New Year, there are others making claims about what is to come in the New Year, for the purpose of informing, entertaining or somewhere in between. Whether you’re into technology, science, politics, or the movies, there are no shortage of predictions – some more serious than others – for what the new year will bring.

In this vein – and walking the line between being informative and being entertaining (as is generally always my goal with my posts – this time leaning more to the latter than the former) – here are my top 3 project management predictions for 2016.

Projects Will Still Have Issues in 2016

I feel ok about the lack of a **spoiler alert** on my number one prediction for projects in 2016, since I can’t image that this has come as a surprise to anyone. While a new year comes with new beginning and (hopefully) a renewed sense of ‘this time it will be different’, the reality is that projects have issues. Always have. Always will. To be clear, this is not an admission of defeat; not by any stretch. It’s simply a recognition of what is real. Despite the best laid plans, the best of intentions, talented, hardworking teams, solid processes, training and experience, there will be risks and there will be issues. Timelines will sometimes be unrealistic. Requirements will sometimes not be as clear as they could/should be and the list goes on. All that said, good teams will recognize this, plan for the known-unknowns, anticipate having to deal with the unknown-unknowns and most importantly, support each other when the going gets tough.

People Will Still be Talking About Agile

In 2001 the Agile Manifesto was created by representatives from various areas of the software development community, as a collection of guiding principles that challenged long-held notions and methodologies for application development. And while the manifesto was created in 2001, the principles and “lightweight methodologies” that it is based on were in use long before 2001, with “scrum” dating back to the early-nineties, and concepts around ‘iterative development’ dating back as early as the 1950’s.

To come straight to the point. This stuff isn’t new. Yet, it has been the sort of topic has that remained relevant over many decades. To even compare to the 2001 date of the formalization of the manifesto, 2001 was the year that Microsoft released Internet Explorer 6, Windows XP and the original X-Box; Napster had a user base of 26 million users and the Compaq Presario was the hottest new computer on the market – and you don’t hear much talk about these things anymore, do you?

For one reason or another Agile has and continues to be a hot topic in the world of software development. Traditionalists like to argue that it’s nothing more than an excuse not to plan or document requirements, while proponents are quick to dispel these notions and point out that ‘responding to change over following a plan’ and valuing ‘working software over comprehensive documentation’ results in a better product in the end. All the while, the training and certification industries are trying to make everyone ‘certified practitioners’ and ‘scrum-masters’ by spamming your inbox every chance they get, claiming that Agile is the silver-bullet you’ve been looking for.

And as if there isn’t enough to debate, I have even heard people debate over the pronunciation of Agile, as apparently that is a thing. Who knew?

So, whether it’s to defend the viability of the approach/methodology, to defend a principle or a process, or to debate its pronunciation, I predict that people will still be talking about Agile in 2016.

Project Management Will Still Not Be All That Exciting

As this article does a great job of describing – through a conversation between Leonard and Penny on an episode of the Big Bang Theory, Project Management is a bit like physics:

Penny: “So, what’s new in the world of physics?”

Leonard: “Nothing.”

Penny: “Really, nothing?”

Leonard: “Well, with the exception of string theory, not much has happened since the 1930’s, and you can’t prove string theory, at best you can say “hey, look, my idea has an internal logical consistency.”

Penny: “Ah. Well I’m sure things will pick up.”

This is to say – from my perspective – that while, there are certainly advances in project management methodologies, tools and techniques (a few for 2016 here), they aren’t often (or ever, with the exception of perhaps Agile – see above) flashy or garner much attention. That said, behind every project involving Big Data, Artificial Intelligence, Cloud Computing, Virtual Reality, or whatever emerging technology is in play, rest assured that there is a Project Manager – and a project team, working tirelessly behind the scenes.


1 Comment

Filed under Business, General, Innovation, Management, Project Management, Strategy, Uncategorized

Please Stand-by to be Processed


Let’s begin with a quote from Alistair Cockburn, one of the initiators of the Agile movement in software development.

‘While a good process can’t assure delivery, and a good team can deliver despite an unwieldy process, a poor process can get in the way quite neatly’.

In case you haven’t figured it out by now, this post is about process. What it is. What it isn’t. Common misconceptions. Benefits. Implementation strategies.

What is a Process?

An established, step-by-step way of doing things, and a well-articulated set of internal and external documents and tools supporting it.

This is, of course, one definition of any number that may be out there. Another, more succinct definition (of sorts) that I’ve heard used is, ‘applied common sense’.

What isn’t a Process?

Magic. A silver bullet. A panacea. As the first quote above notes, a good process can’t assure delivery. That said, it’s a place to start. A baseline from which to begin and to continuously improve from. Even for the Agile purists that declare as part of their Agile Manifesto to value ‘Individuals and interactions over processes and tools’, are in fact rather processes driven in their own way through adherence to Agile processes and practices such as user story modeling , iterative development and time-boxing.

Preferred methodology aside, we could all benefit from a little bit of process – though not everyone is convinced.

Common Myths Associated with Process

  • Adds unnecessary steps and time
  • A form of micro-managment
  • Adds documentation for documentation’s sake
  • Limits creativity
  • Limits flexibility

These are common reasons why establishing (and documenting where appropriate) processes on a team or within an organization is often met with resistance.

On the other side of the coin, having a solid process that is understood, documented and followed can truly be the difference between success and failure on a project. And while it may not always be readily apparent from the outset, process can have numerous benefits for everyone involved. Here are 10+ that come to mind.

Benefits of Process

  1. Repeatable. Predictable. Manageable. Having a process in place will help to ensure that your delivery process is repeatable, predictable and manageable which has obvious associated benefits – as well as others explored in the subsequent points.
  2. Maximized efficiency. Minimized waste. To be able to hit the ground running on the actual work to be done vs. spending time defining the steps (the ‘how) and/or the creation of templates/documents/assets etc. to facilitate the work.
  3. Clear expectations. So everyone knows what they need to do, what everyone else needs to do, and what the timing and dependencies are.
  4. Reduces risk. By having processes in place related to the risky areas of delivery, risks are identified and mitigated early.
  5. Reduced re-work. With risks and/or issues caught earlier, the likelihood of costly re-work is reduced.
  6. Better quality product. With risks and/or issues caught earlier and the ‘how’ figured out in advance, the time and energy on the project can be focused on developing and testing the product, and the results will show.
  7. Reduced interruptions. Increased focus. Increased productivity. If there are still any skeptics, hopefully this one will help to convert them. While still having processes and steps in place related to the above points (e.g. risk identification and mitigation), an objective of any process should always be to provide more focused time for the team to do their work.
  8. Better awareness of the big picture. With a process in place and documented, everyone can see how their contributions fit into the larger picture.
  9. Cross training and professional growth. When processes are established and documented, it’s easy to train team members and new hires on how things are done to allow people to advance their career and not be ‘stuck’ having to take care of a certain task because he/she is the only one that knows how to do it.
  10. Increased customer satisfaction. Increased employee morale. With all of the above considered and addressed through the implementation of a process what works for your particular project/business unit/organization, the collective result will be increased customer satisfaction and increased employee morale, which is obviously good for everyone.

So now that we’ve seen the benefits of process, here are a few strategies for successful implementation.

Implementation Strategies

  • Alignment. When developing, documenting and improving your processes, take the time to step back and make sure it aligns with the goals and values of your organization, project and team members. Much like understanding how a work package or a test case maps back to a requirement in a delivery project, the way you get things done should also map back to individual, team and company goals.
  • Collaborate. Work collaboratively to develop your process with the people that will be using it. Seeking inputs from everyone will go a long way to ensure you have considered all of the areas and will also increase likelihood of adoption.
  • Don’t over analyze. While it’s important to not create a process in vacuum, not consulting and collecting inputs from all the stakeholders, be mindful of getting into analysis-paralysis mode trying to make it perfect for everyone. Take a page from the ‘Lean’ start-up playbook and seek to get your MVP (Minimum viable product) out there and then improve it over time.
  • Continuously improve. Further to the above point, processes should evolve and improve, so be active with looking for ways to make this happen. Process is not a one shot deal. Continuous improvement is key.
  • Understand that one size doesn’t fit all. Figure out what works for your team, your customer and your project and tailor accordingly. Consider having a step in the process to evaluate and tailor the process for each project, adjusting up or down based on factors such as the project’s size, type, technology and customer.

Leave a comment

Filed under Business, Business Analysis, General, Innovation, Management, People, Project Management, Strategy, Uncategorized

10 Ways to Manage Project Scope

Let’s talk about scope.


Not that kind of scope. Project scope! The “what’s in”, the “what’s out” and “how you are going to manage it” kind.

In my previous post, I outlined the 10 Project Management Knowledge areas, one of which was ‘Project Scope Management’, which the PMBoK (5th Edition) defines as,includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully”.

Well that sounds easy enough, right? So, what are these processes you speak of? They are:

  • Plan Scope Management – the process of creating a scope management plan that documents how the project scope will be defined, validated and controlled.
  • Collect Requirements – the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
  • Define Scope – the process of developing a detailed description of the project and product.
  • Create WBS (Work Breakdown Structure) – the process of sub-dividing project deliverables and project work into smaller, more manageable components.
  • Validate Scope – the process of formalizing acceptance of the completed project deliverables.
  • Control Scope – the process of monitoring the status of the project and product scope and managing changes to the baseline.

While all of the above processes are important when it comes to scope, the one that seems to get discussed the most in one form or another is the ‘control scope’ process. In fact, while ‘controlling scope’ is the context in which the conversation is often framed, the processes – as you’d expect – relate very closely to one another, so doing a good job in one area will often yield dividends further downstream. For example, if you do a good job of collecting requirements to establish what the scope actually is, this will help you when evaluating potential changes to the scope during the project, and when validating that the scope was met before you finish.

Also, still on the subject of ‘controlling scope’, depending on your chosen methodology, the process for collecting, documenting and managing the requirements that will largely drive your scope may not be following a traditional waterfall type of process where all requirements are known and documented prior to development. Understanding this, the notion of ‘controlling scope’ should be something that is balanced with having processes in place that will allow more detailed requirements to become clear as the project evolves, to ensure that the developed solution is addressing current and relevant requirements for your customer.

So while processes should always be tailored to the project, as no two are every completely alike, here are 10 ways that you can manage scope on your projects.

  1. Understand the business drivers, pain points and customer objectives for the project. Establish a shared vision. Getting everyone on the same page for what is it you’re building and why will be the foundation for all of the decisions you make on the project.
  2. Take the time to define and agree upon requirements. It’s always tempting to want to jump directly into building the solution, but take the time (regardless of your methodology) to agree on some requirements first.
  3. Establish a scope baseline. Acknowledge that changes may need to occur but agree to evaluate them against the agreed upon baseline.
  4. Ensure all key stakeholders, users and SMEs were involved in the requirements process. If any key stakeholders were left out, they could emerge later and add scope that could have impacts on the project.
  5. Ensure that due diligence was performed when defining scope and associated estimates and timelines. Make sure the team understands the complexities and effort for what you’re now on the hook for delivering. Ask questions. Document assumptions. Review with the client to get on the same page for whether you’re building a ‘Cadillac’ or a ‘Pinto’.
  6. Break the work into manageable pieces. If your WBS has a task that reads something like – ‘Feature 1-development: 80 hours’; this is a WAG, not a proper estimate, so you should take the time and energy to figure out how to decompose this work package into smaller tasks that can be properly estimated, otherwise accept that there is some risk in this ‘estimate’.
  7. Acknowledge that scope creep can kill a project (and beware of Gold Plating). Get agreement from the team from the client that sliding in even seemingly small changes has the potential to impact your project. This could include things that the client is asking you to add in, as well as little things that project team members might try and add in, in hopes to add some extra value (‘gold plating’). In the latter scenario, while these types of things are often well intended, it’s often the additional little item that will be the thing that results in an issue down the road.
  8. Develop and validate iteratively. While this may depend on your chosen methodology, showing progress will go far to allow the custom to validate parts of the solution along the way (thus reducing risk) and will also establish trust.
  9. Maintain a ‘wish list’. As change requests are raised and evaluated, maintain a ‘future enhancements’ list of items that weren’t able to be added to scope for the current release, as candidates for a subsequent release.
  10. Have a change control process. Last but certainly not least, establish a process for addressing changes. How to raise a change, how to evaluate/assess impact and who is responsible for approving or rejecting it. The change control process should allow time for the impact analysis itself, since even the process of performing the assessments (particularly if there are many changes being requested) can have impacts on the project, as team members need to shift focus from delivery of in scope features to assessment of changes.

1 Comment

Filed under Uncategorized

Here a BoK, There a BoK


Everywhere you turn these days there’s another group publishing their own BoK guide. A BoK, referring to a ‘Body of Knowledge’, of course. You’ve got your BABoK, the Business Analysis Body of Knowledge – a staple in the library of any self-respecting BA. There’s the SWEBok, the Software Engineering BoK for developers, architects and software practitioners; the QBok for the QA’ers; the UBoK for Usability professionals, and of course everyone’s favourite (Ok, maybe just my favourite), the Project Management Body of Knowledge, or PMBoK.

Before I proceed any further into this post I feel compelled to mention that if you work in any of the above noted areas and aren’t familiar with your respective BoK (or perhaps weren’t even aware there was such a thing) – don’t fret! It is entirely possible to be competent in your field without having your field’s BoK committed to memory!

I can’t speak for any of the aforementioned BoK guides other than the PMBoK, but the PMBoK – when outlining its purpose in its first few pages – is quick to note that is absolutely not a prescriptive ‘how to’ for managing projects. Rather, it is a culmination of ‘knowledge, processes, skills, tools and techniques’ that are ‘generally recognized’ as being ‘good practice’.

The PMBoK goes on to note what should be fairly obvious, that the concepts in the PMBoK guide are not intended to be uniformly applied and that the organizations and project teams delivering the projects are the ones responsible for determining what is appropriate for the individual projects being undertaken.

Whew! We’re not all going to be replaced by robots, mindlessly executing steps out of the PMBoK. That’s a relief!

As anyone who has ever worn the PM hat (whether it is was formally recognized as your role or not) knows, that while BoK guides and other theoretical tools can be handy (as paper-weights or door-stoppers, some might say), when looking for a consolidated view of industry best practices, quite often the real difference between a successful project and an unsuccessful project comes down to things like the intuition, judgment and experience of the team during the delivery of the project. Adaptation over adoption. Art vs. science.

That said, a little theory never hurt anyone either. Why not benefit from the collective knowledge of your peers and arm yourself with some knowledge and best practices that may just prove useful along the way?

With this dichotomy in mind, I thought I would create a few posts that will outline some of the core concepts from the PMBoK (and/or some other PM literature) in order to share some project management best practices. For the PMs in the house, most of this will be a refresher. For the non PMs out there, I definitely encourage you all to continue reading as well, as my hope is that doing so will give you a greater understanding and appreciation for all of the things bouncing around inside the head of your project managers!

As a starting point here is a quick overview Project Management Knowledge Areas and their PMBoK definitions. As I noted, in future posts I’ll do a deeper dive into some of them, weaving in some of my thoughts and experiences along the way.

  • Integration Management – includes the processes and activities needed to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups.
  • Scope Management – includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.
  • Time Management – includes the processes required to manage the timely completion of the project.
  • Cost Management – includes the processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling costs so that the project can be completed within the approved budget.
  • Quality Management – includes the processes and activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken.
  • Human Resource Management – Project Human Resource Management includes the processes that organize, manage, and lead the project team.
  • Communication Management – includes the processes that are required to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and the ultimate disposition of project information.
  • Risk Management – includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project.
  • Procurement Management – includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team.
  • Stakeholder Management – includes the processes required to identify all people or organizations impacted by the project, analyzing stakeholder expectations and impact on the project, and developing appropriate management strategies for effectively engaging stakeholders in project decisions and execution.

Leave a comment

Filed under Uncategorized