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

Project Managers are from Jupiter


The idea that ‘Men are from Mars and Women are from Venus’ has been well documented. A lesser known astrological fact that you may not be aware of however, is that Project Managers (regardless of gender) are from Jupiter. It’s true.* (*not really)

You may be thinking, that this actually explains a lot.

How many times have you been on a project where your PM schedules you for a status meeting and then – later in the day – asks you why you are late with a deliverable? ‘Uh…because I was in your status meeting, not at my desk getting my work done?!’, might be a common response to such a question that could only be posed by, and make logical sense to, someone from another planet, not governed by the same laws of time and space that ordinary earthlings are bound to abide by.

Or, what about the classic PM request, ‘Please make sure that you provide assumptions to support your estimates’. Or, the ever popular questions, ‘What is your percent complete?’, or ‘What is your estimated completion date for that deliverable?’

For the Project Manager’s out there, how many times during a project do you have a team member looking back at you – like you are from another planet? ‘You want me to attend meetings, and still get my work done?’, ‘You want me to estimate a task and write assumptions when I don’t even have detailed requirements?’, ‘You want me to guess at how much longer something is going to take when I have this project plus 3 others on the go?’.

So now that you know that your PMs, with all their illogical and nonsensical questions and requests are actually from another planet, does that make things fall into place a bit better?

Kidding aside, projects require different roles and skills sets. And while we all share common goals on a project such as delivering on time, on budget, to the agreed upon scope and level of quality – and other such ‘traditional’ notions of project success – sometimes the particular goals and motivators of the various team members and roles are not all that well understood.

As such, I thought I would take the familiar ‘Men/Mars, Women/Venus’ metaphor to outline a few ‘quick hits’ in terms of how a PM’s brain (generally speaking) is wired for hopefully an increased understanding and appreciation for how things work ‘on our planet’.

Scope & Requirements

Project Managers care about scope. No big shock here. We want to ensure it is well defined so that as a team we can deliver it. While it’s the PM’s job to manage scope, all team members have a role to play. PMs and team members alike should keep an eye out for areas where scope has increased in size and complexity, and raise flags accordingly so the PM (or other roles as required) can go back to the customer to discuss these variances.

Schedule & Budget

Projects have schedules and budgets and the PM typically owns the responsibility for managing these items. That said, the PM doesn’t (though this would certainly be cool) get to define the schedule and budget; rather, it is defined by collecting inputs from the project team, in accordance with requirements and expectations from the client. Inputs include things like work packages, tasks, dependencies, estimates, assumptions and risks.

While it may be the PM facilitating the process of bringing all of this together, it is being done for the benefit of the project where each every team member has a stake and is accountable in their respective area. As the project moves along, the schedule and budget defined at the outset of the project needs to be kept up to date and reported against. This involves understanding things like task percent complete estimates, target dates for deliverables and milestones, and updated estimates/forecasts.

Communication (and collaboration)

If you’ve ever worked on a project, you’ve probably seen a meeting invite or two from your PM. PM’s schedule meetings; it’s part of what we do as part of the ‘Communication Knowledge area’ to bring the right people together to get things done. Sometimes it’s about collecting inputs for a ‘PM deliverable’ like a SOW, or a CR. As these are deliverables that the project team will be delivering to and will be accountable for, you should hope that your PM is involving the team and not working in a vacuum on these sorts of things.

Sometimes meetings will be about facilitating the process of getting teams and stakeholders connected with each other to ensure everyone is getting what they need from one another. Has the BA had sufficient time with the correct mix of clients, stakeholders and subject matter experts to collect and document the requirements? Has the development team had sufficient access to the BA to fully understand the requirements that they are working against? Does the QA team know what they’re testing? Are there nuances with the requirements documents that may not be readily apparent without some face time with the development team? These are (among other things) the things that keep PM’s awake at night! As such, during the day (and sometimes nights as well), PMs schedule meetings to ensure these questions are answered – for everyone’s benefit.

Last but not least – and despite some traditional ideas of space dwellers (or PMs for that matter) – we want harmony in the universe. Just like you, we want to get things done on time/budget/scope/quality, all while doing great work, doing the right thing, keeping our customers happy and hopefully enjoying ourselves in the process. Let’s work together to get it done!

Thanks for reading. Live long and prosper1.

1Reference: Spock

Leave a comment

Filed under Management, People, Project Management

Hackathon – Top 10 List

As I noted in a couple of earlier posts (see below for links), I have organized a couple ‘Hackathons’ over the past couple of years. During the process of organizing, marketing and recruiting for these events I spun up another WordPress site http://truegrowthhackathons.com to promote the events.

I also created, and was involved with the creation of, various other marketing and promotional materials. One thing that I created that I thought was sufficiently cool was this ‘top 10’ list. Something of an ‘un-top-ten list’ you might say. While I don’t have any specific metrics to know how many people attended the hackathon as a direct result of this piece, I like to think that it factored in to what ended up being a pretty great event!



Top 10 list

Leave a comment

Filed under Events, Hackathons, Innovation, Marketing

Broken Windows. Software. Process and Disorder.

broken window

Studies in the fields of criminology and urban decay have repeatedly found an interesting trigger mechanism – one that turns a clean and intact building, into a smashed and abandoned one. Care to hazard a guess what it could be?

A single broken window.

That single broken window, left unrepaired for a period of time has invariably lead to the rapid decline of the building and its community.

How does this happen?

It happens as a result of the sense of abandonment felt by those that live in and around the building; the sense that the powers that be don’t care about the building. So another window gets broken; then another. Later graffiti appears, followed by damage to the structure of the building. The spiral then continues until it gets to the point where the damage is beyond the building owner’s desire or willingness to fix it.

In one experiment in 1969, Stanford psychologist Philip Zimbardo arranged to have a car without license plates parked with its hood up in the Bronx, New York and another in Palo Alto California. In the New York example, vandals attacked the car within 10 minutes of its ‘abandonment’ and within 24 hours everything of any value had been taken. In California, the car sat untouched for more than a week. At this point Zimbardo himself smashed the windshield with a sledge hammer and then within minutes people passing by were joining in and then within a few hours the car was turned upside down and completely destroyed.

Social scientists Wilson and Kelling wrote about this ‘Broken Windows Theory’ in the March 1982 issue of ‘The Atlantic’. In this article they made these ‘inextricable linkages’ between disorder (or at least the perception of disorder) and crime. The New York vs. California example above – also referenced in the piece – notes how ‘untended property becomes fair game for people out for fun or plunder and even for people who ordinarily would not dream of doing such things and who probably consider themselves law-abiding’, and further, ‘vandalism can occur anywhere once communal barriers – the sense of mutual regard and the obligations of civility – are lowered by actions that seem to signal that “no one cares”’.

The Broken Windows theory has been credited in part for community based policing initiatives in various cities, perhaps most notably in New York City under the leadership of Rudolph Giuliani in the 1990s, where the focus was put on small crimes (e.g. vandalism, subway turn-style jumping) as a means of the prevention of larger crimes – by creating an atmosphere of order and lawfulness.

So, what does this have to do with software development?

Since the Broken Windows theory was theorized, software development teams have found inspiration in it, as a metaphor for focusing on the small things in order avoid larger problems down the road. Dealing with the ‘broken windows’, if you will, since ignoring them can result in ‘technical debt’ that will eventually have to be paid.

The idea is, that in addition to ensuring you’re doing all the right things – sweating the [seemingly] ‘small stuff’ – you’re not only developing a higher quality solution, you’re also creating an atmosphere on your project/team/company where process and quality matters. The Broken Windows theory as it applies to software development – generally speaking – asserts that issues should be dealt with before any further code is written. If the build doesn’t compile – fix it now. If there are bugs – fix them now. While this sounds simple enough, it’s not always the way it goes for one reason or another.

While each team and even each project for that matter will have different sets of processes for different reasons, there are still principles from this theory that can be used. Make it a point to agree on processes and standards for delivery. From unit tests, to comments and documentation, continuous integration and bug fixing – establish what your process and expected quality levels are and stick to them; even when you’re busy.

Especially when you’re busy.

In fact, ensure you’re working closely with whoever needs to be involved to make sure that you don’t find yourself constrained to the point where you’re unable to do all of these ‘little’ things, since that is a slippery slope to somewhere you don’t want to be.

I would further assert that this goes far beyond strategies related directly to the software development/coding aspect of solution delivery. Teams should also ensure that the overarching processes for solution delivery are agreed upon and maintained. While adherence to processes around things like communication, status reporting and risk analysis can sometimes seem like easy-pickings for corner cutting, the outcomes of doing so can lead you to a place where you could find yourself wondering how you got there.

One broken window at a time.

Reference: http://www.theatlantic.com/magazine/archive/1982/03/broken-windows/304465/

Leave a comment

Filed under General, Management, People, Project Management, Strategy

I Have the Power!

I have the power

In 1959 a couple of psychologists (French and Raven, 1959), published a study on ‘The Bases of Social Power’. It looked at the relationship between power/influence and leadership, defining various types of ‘power’.

Since this time, this study and the ‘power types’ defined within it has been referenced – explicitly or  implicitly – in leadership related literature, to help organizations and individuals understand the various types of power that exist and what that means for those that have it and for those that are influenced by it.

For the purpose of this post, I will a provide a brief, high level summary of the power types from the perspective of how I have seen and experienced them in my role as an IT Project Manager.

Legitimate Power

This type of power is associated with position. A CEO has legitimate power by virtue of being at the top of the organizational structure. Similarly, your business unit leader, direct supervisor or your Project Manager has legitimate power as a result of formal authority they have had bestowed upon them. When they say jump, you say – ‘how high’? Right? Well, not necessarily, but that’s the idea when it comes to legitimate power.

In the context of legitimate power in Project Management, how much ‘legitimate power’ / formal authority a Project Manager has over his/her team members will depend on a number of things. Most notably, it will depend on the organizational structure of the company. In ‘Functional’ organizations, where employees are grouped into specialties (e.g. Engineering, Marketing etc.), Project Managers tend to have limited authority, as employees tend to be loyal to their ‘Functional’ group and manager over their project and Project Manager as a result of the organizational structure and related items such as role descriptions and reward programs.

‘Projectized’ Organizations – at the other end of the spectrum (with weak and strong matrix organizations in between) – are structured such that the Project Manager – through the creation and sign off of the Project Charter – has the formal authority / legitimate power for that particular project and employees will report into him/her during the life of the project.

While the organizational structure would likely be influenced by the nature of your business, it’s worth mentioning that the type of business you’re in could be a factor in the prevalence of legitimate power in your company or team. Are you a consulting organization where adherence to delivery processes is vital in your ability to meet tight timelines and quality standards? Are you a product shop where the generation of innovative product and/or feature ideas trumps all? Would you expect the prevalence of legitimate power to be different in these two scenarios?

Lastly, the use – and effectiveness of – legitimate power will also largely depend on such things as the culture and norms of the organization and its teams. Does your organization/team/team members place a high value on Project Management as a discipline? How is this demonstrated and how does it factor into the use and effectiveness of legitimate power?

Reward Power

Reward power is also related to position, but perhaps to a somewhat lesser extent. Basically, it is the power that someone holds as a result of the control they have in issuing ‘rewards’. Again, depending on the type of organization you are working for, and the cultures and norms within it, who has this control may vary. Going back to the Functional Organization example, are employees likely to ‘go the extra mile’ for their project and Project Manager if the Project Manager has no say in things like whether they get a raise/bonus/incentive for doing so?

In a pure Projectized organization, the Project Manager would have the authority for issuing rewards – or there would at least be a process in place whereby Project Managers would have a line of communication to Functional Managers to provide feedback on an employee’s performance for the purpose of issuing rewards commensurate with their performance – which would help provide incentive from a reward power perspective.

All that said, while ‘extrinsic’ rewards such as raises/bonuses/incentives often come to mind as ‘rewards’, there are also many ‘intrinsic’ rewards that Project Managers can have control of, regardless of organizational structure or culture. This could include things like a favourable assignment within the project, or recognition – be it public or private depending on what you know about your individual team member’s personality type and preferences – for a job well done. Sometimes a simple ‘Thank you’ can be a nice reward.

Coercive Power

Coercive power could be described as the opposite of reward power, as the two are very closely related. Basically it is the power (or perceived power) that someone has to threaten or punish someone else as a tactic for performing certain tasks or achieving certain results. This could mean the power to withhold a reward, or to threaten such things as a demotion, pay-cut, lay-off, termination etc. This type of power – as you would expect – has been associated with lower levels of job satisfaction and higher levels of turn-over.

Use of this type of power is generally agreed to be less effective in the long term and has been more commonly associated with older, outdated ‘command and control’ styles of ‘leadership’.

Expert Power

Expert power is a type of power/influence that is more personal than positional/formal. As the name suggests, it’s about the power you have as an expert in a particular area. This could mean a variety of things, including but not limited to: being the resident guru of a particular technology (e.g. a programming language); being the team member with the most experience in particular field; being a particularly good communicator; or having a knack for identifying and mitigating project risks.

As these examples suggest – and as noted regarding expert power being personal versus positional – anyone can have expert power and there are many areas people can become experts in. Project Managers, as with any role, can build their credibility as experts in their particular areas through actions such as obtaining and maintaining industry certifications (e.g. PMP, CAPM) and continuously improving their skills using all of the lessons they learn on projects along the way.

Reverent Power

Reverent power is closely related with Expert power, as the 2nd type that is personal versus positional. This power type is related to interpersonal skills and relationship building. It is about being able to influence as a result of trust, respect and mutual admiration built over time, versus through any formal authority granted.

As you might imagine, this isn’t something that is easily obtained – and not something that can simply be a blurb in a project charter. Project Managers – and others alike – have to earn this type of power. As you also might expect – with today’s flat/non-hierarchical organizational structures, Reverent Power is arguably the most important type of power as leaders have to be able to achieve results, influencing often with limited formal authority and varying degrees of control over reward systems.

Leave a comment

Filed under Management, People, Project Management