Monthly Archives: April 2014

Why Projects Fail

homer failure

I’m sure you have all seen these types of lists on various websites or in your twitter feed (or maybe you haven’t because you subscribe to more interesting types of content than I do), because there are many of them out there. In fact, they write books and publish reports about this sort of thing. Why? Because projects keep failing and we keep trying to figure out what we can do to ensure that OUR projects don’t fail. (Editorial note – I realize that even the term ‘failure’ can be quite subjective and they write books about that sort of thing too).

So, why DO projects fail? Good question, right? Here are a few reasons, from my experience.

1) Unrealistic schedule and/or budget

Ok, this was an easy one so I won’t spend too much time on it. It is worth noting, of course, since it often happens that project schedules and/or budgets that are put forward to ‘win the business’ are often challenging to deliver on by the project team. That said, seeing these sorts of gaps – between what the client is dictating, or what a proposal team thinks is necessary to win a bid, and what a delivery team thinks is realistic – should be thought of as a trigger to review and ensure that delivery processes are as efficient as possible so as to close this gap. Do we REALLY need 3 months to deliver this feature that the client or proposal team thinks we should be able to deliver in 2 months? Maybe the answer is yes, but maybe it’s not. Is there a better way?

2) Poorly Defined Requirements

Ok, this is a bit like shooting fish in a barrel but no list of this sort would be complete if there wasn’t at least a mention of what seems to be everyone’s favorite reason for project failure. As anyone who has ever worked on a project can attest to, there are varying degrees of requirements and an infinite number of ways things can be interpreted. (This cartoon does a nice job of summing that up, I think). Depending on the methodology you favour (i.e. ‘Waterfall’, RUP, Agile etc.) you may have different views on how best to capture and manage requirements but regardless of methodology, common sense should tell you that there must be some level of agreement between the delivery team and client as to how the schedule and budget are going to be spent. (You wouldn’t ask a contractor to build you a “house” without ensuring there were a set of blueprints that you have reviewed and signed off on, would you?)

That said, far too often we find ourselves on projects where budgets (sometimes unrealistic ones – see #1 above) can’t support the creation of requirements that will help to ensure there is a ‘shared vision’ of the solution before it is developed, or with project schedules (sometimes unrealistic ones – see #1 above) that are created such that development must be expedited! in order to meet an externally imposed milestone date. Is it any wonder that projects end up over budget, behind schedule or with clients that are unsatisfied with the results?

There is no, one right answer, however when it comes to requirements, like many things, it’s about communication (see # 4 below). Communication between the client, stakeholders and team to figure out how best to come to agreement on getting the delivery team a CLEAR road map to deliver against, AND ensuring that there is adequate* (see last section of #1 above) time and budget allocated in order to do so.

3) Poor Role Definition

While budgets and schedules can sometimes be imposed on project teams, defining the “who’s doing what” is something that should be completely within our control. Even though this should be the case, quite often projects find themselves over budget, or behind schedule, or with sub-par levels of quality because, quite simply, people didn’t know what EXACTLY they were responsible for. The result? Well, there can be many. 1) People don’t get invested in the project 2) ‘Something’ doesn’t get done. 3) ‘Something’ gets done by a combination of people which results in a) more time spent on a task than budgeted b) no true owner, accountable for the result.

Defining roles sounds like a bit of a no-brainer, right? Designers, design. Developers, develop. QA testers, test. Easy. Well, while this is true to a certain degree, it’s all the little bits in between that can mean the difference between project success and project failure. When defining roles and the various nuances that can exist within and across them it’s CRITICAL that clear ownership is established so that when there is a task that needs to be completed or there is a decision that needs to be made, everyone knows who is responsible. As a result: 1) People get invested in the project because they know what they are responsible for and they (more often than not) get excited about delivering it; 2) Things get done.

As such, taking the time prior to the project kicking off to clearly establish who is responsible for the various aspects of the project and how their role may intersect or overlap with other roles on the project is, in my view, time very well spent.

4) Poor Communication

This one in particular could be a blog post, or even a book on its own, but I’ll touch on a few, of what I feel, are important points on the subject. Communication, as it relates to project delivery, doesn’t mean having a trillion word vocabulary, or the ability to deliver the opening keynote at a TED conference, or even an understanding of the proper use of a dash versus a hyphen (though these would be considered assets, I suppose). It’s firstly, about the understanding of the NEED FOR communication. Communication between the team; communication with the client; and communication with management and other stakeholders.

Secondly, it’s about understanding that communication is EVERYONE’S job. Project managers are typically the owners of the project status report and its delivery, but ensuring that it has all of the necessary inputs – from current and planned tasks, to risks and issues, to current status of scope, budget and schedule – should be a process where all team members are expected to contribute. As such, all team members should – in addition to their roles to design, develop, test etc. – EXPECT to have to (and hopefully also WANT to, as this is THEIR project too) communicate such things as: 1) Status – planned vs. actual; 2) Issues/Risks; 3) Anything else they think might be relevant for discussion (your Project Manager is here to listen!)

This isn’t to say that every team member needs to be present in every status meeting and copied on every email; quite the opposite, in fact. It IS to say that every project, in some form or another, (level of detail and rigour will depend on things like scope, budget etc.) should have a communication plan that will define things like 1) who needs to be in the status meetings and 2) who needs to be copied on emails. (See # 3 Role Definitions above. See how this is all coming together?).

5) Scope Control & Change Management

Closely related to #2 (Requirements), Scope Control and its close relative Change Management really HAVE to be included in any ‘Project Management Top 10’ type of list like the one you have almost finished enjoying.

As this one is probably the most obvious one of those listed, I’ll keep my points brief since, in my view (though it is certainly easier said than done), mitigation strategies for preventing failures in this area should be equally brief and simple. Scope. Define it. How to deal with changes (and YES, there WILL be changes). Define that too. Remember, the process shouldn’t be about locking things down so tight that change can’t happen; it’s just about having a process).

So, this is obviously not an exhaustive list but just a few ‘reasons projects fail’ that I have seen, along with a few ideas for how to mitigate failures in the future.

Leave a comment

Filed under Management, People, Project Management

Finishing up the MBA (Update 3 of 3)

mba graphic

Reference the original post here:

Lastly, the other thing (in addition to the other retroactive updates I’ve posted, plus my full time job as an IT Project Manager and my role of husband and father – my favorite role, incidentally) that has been keeping me away from the important task of updating my blog has been completing the last few courses toward my Masters of Business Administration (MBA) at The University of New Brunswick – Saint John. This was a pursuit that I started in 2009, on a part-time basis, so it has been quite a few years in the making. Completing the program has been an enjoyable experience – except for all of the work! (kidding, mostly)

Kidding aside, the program really has been fantastic, with a great mix of streams, courses, professors and students to learn from. The professors were a good mix of ‘academics’, executives, entrepreneurs and industry experts, and students ranged from other working-professional types to full-time students from countries all over the world – China, India, England, France, Saudi-Arabia, Mexico, Brazil, Egypt, just to name a few off the top of my head thinking of students I’ve met and worked on projects with. The program even recently cracked the list of ‘Top Ten Canadian Business Schools’ published by Business Review Canada. Kudos UNBSJ!

While this MBA had all of the ‘core’ business and management type courses covered – from Marketing and Accounting, to Economics, Strategy and more, it also had a great mix of courses and assignments that allowed me to expand my knowledge and perspective in a number of other areas as well. Here are just a few quick examples:

  • Human Behaviour – understanding personality types, starting with – and perhaps most importantly – my own. Appreciating how differently people absorb, process and act on information. From your introverts, to your extraverts and those somewhere in the middle (omniverts, you say?), recognizing that not everyone does things the same way, and making the appropriate adjustments, is key if you’re managing, or even just working with, people.
  • Leadership – following closely on the human behaviour element noted above, the topic of leadership is huge with so many different facets. From leadership styles (task based vs. people based; autocratic vs. democratic etc.), leadership types (i.e. servant leadership, transformational leadership), to understanding motivation, Emotional Intelligence and the list goes on.
  • Ethics & Sustainability – exploring the policies and practices of organizations in many shapes, sizes and industries, looking at topics such as clean technology, innovation and product stewardship.
  • Renewable Energy – learning about energy types such as solar, wind, tidal, geo-thermal, among others. Exploring them from not only technological perspectives, but from economic and social perspectives as well.

The program also did a nice job of integrating the research and course work into initiatives that were able to provide value to the communities we are working in. A couple of examples include:

  • Wicked problems: A project that involved working closely with a local municipal department to understand and analyze issues they face, that are largely agreed upon as being ‘wicked problems’ – or problems that are difficult, if not impossible, to solve – for a multitude of reasons. (Here’s a great site and video that sums it up the idea of ‘wicked problems’ or you can read the paper where the idea originated from.) Though perhaps unsolvable by their very definition, we were able to view the situation through a different ‘lens’, and through our research and consultation we were able to present some ideas and findings that were able to add some real value.
  • Buy local: A project where we were tasked with making a case for local private and public corporations to procure ICT services from local providers. In doing so, our objective was not only to put forth a compelling ‘economic argument’, but a ‘social argument’ as well. In putting this together we looked at the practices being undertaken by countries that are global leaders in IT such as Finland and Iceland to make some extrapolations for what a ‘buy local’ strategy could mean for us locally. (See an earlier post on this here).

So, there you have it. That’s everything I learned in the MBA. I’m kidding, of course, but these are just a few of the areas that spring to mind where I feel the program provided some additional value beyond what most would consider core MBA type material (fun stuff, like NPV and IRR). Isn’t learning fun!?

In any case, it will be good to be finished, however from chatting with some of my part-time counterparts working for other companies that have finished before me, there’s a chance – so I’m told – that I may even miss it. (One even made a lose comparison to the concept of Stockholm Syndrome, which (upon looking it up) I thought was pretty funny). I guess time will tell.

Thanks for reading. More posts to follow (on a semi-frequent basis).

1 Comment

Filed under Business, Management

T4G Big Data Congress II (Update 2 of 3)

big data

Reference the original post here:

Last year (2013), the company that I work for, T4G, organized an event that we called the ‘Big Data Congress’ to talk about Data Science and what it means for business. We had organized some events before, but nothing ever like this. We brought in world-leading industry ‘thinkers’ and ‘do-ers’ such as Andrew McAfee, Tom Davenport and Stephen B. Johnson among many others, along with a host of local industry leaders to talk about Big Data. To cap it off, we had maritime favs The Joel Plaskett Emergency close out the day with a concert. (That was particularly awesome, as I’m a big fan.)

While I’ve been doing IT Project Management for a number of years, this was my first foray into Event Management, so this made the event particularly interesting and informative for me. (Note – for any PMs thinking about getting into Event Management, be forewarned that there is much more standing and physical labour involved in the latter!)

This year (2014) we embarked on trying to top last year’s event, which we knew would be no easy task due to how well executed and received it was. For this year’s event, we went BIG. We increased the scope of the event from a 1-day event, to a 3-day event, complete with world-leading ‘thinkers’ and ‘do-ers’ (among them Rick Smolan, Kevin Slavin, and T4G Big Data Congress returnee from last year, Hillary Mason), ‘technical sessions’ (by popular request from feedback received from last year’s attendees) AND a ‘Student Super-Power Challenge’ (an initiative to inspire high school students to get involved with technology).

Our ‘headliner’ was none other than the WORLD’S top management thinker Clayton Christensen, author of the Innovator’s Dilemma (check out my earlier post for a synopsis if you’re so inclined) and the person that introduced the world to the concept of ‘disruptive innovation’ (among other accolades).

So, while we knew we had a big task ahead of ourselves to top last year’s performance, at the end of the 3 days there was no doubt that we had done just that. A credit to everyone involved, from the organizing team, to the sponsors, to the venue, the volunteers, the speakers, attendees and so many more. Kudos!

Now that the dust has settled and I’ve had a bit of time to reflect, here are just a few of my personal lessons learned that I think will help me for all my projects (and events) moving forward. Hopefully you can read them and take something from them that can help you too.

Think BIG.

Project Managers, either through training, hard-wired genetics, or some combination of the two, are often risk averse. Risk is bad. It must be proactively sought out and destroyed. Managing scope and controlling (or rather, having a process for) change is your reason for being. This is the mantra of the Project Manager. All that said, without having a grand vision of what your project/event/initiative CAN be, you may not be realizing its potential. Scope must be managed. Risk must be mitigated (or avoided, or transferred, or accepted – see an earlier post on some of these strategies if you like), but be careful not to de-risk your project SO much so as to limit its potential to be GREAT! Like many things in the universe, it’s all about balance.

Listen to your customers.

As this was a follow up event to last year’s event there was, of course, some pressure to make this year’s event even better. When figuring out how to go about doing this, we started with looking at the feedback we received from our post-event attendee surveys from last year’s event. One of the things that people were saying that they would like to see for the future was more content on the ‘technical’ side of things. Exploring in more detail some of the actual tools and processes for getting elbow deep into the data. So, with an understanding of what our customers wanted, we added a day of technical sessions. Easily done.

While this sounds simple enough, quiet often it’s easy to become immersed in what you’re doing/developing/planning etc. to come up for air and see what it is that your customers are actually asking for. The somewhat recent advent of the ‘lean start-up’ movement, and similarly the ‘Agile’ development movement, both advocate for frequent contact and validation from customers as opposed to the more traditional notion of going heads-down to develop something that, in the end, nobody wants. While we, in our planning and delivery of the event, didn’t subscribe directly to either of these methodologies, their principles were at work in our ability to solicit and react to customer feedback.

Adapt. Adapt. Then adapt some more.

With this point, I will try and tie the first two points together. In point 1 I noted that projects should be envisioned to be as big as and bold as they can be to accomplish whatever your objective may be, while still managing them so that you are able to actually deliver the goods. In point 2 I noted that a key factor in successful delivery of anything – whether it be a software application, an event, or a Big Mac and fries (depending on your line of work) is to listen to your customers and not ASSUME you know what they want. Sometimes striking this balance can be tough. It’s all about figuring out that sweet spot between level of rigor with regard to managing scope and risk while still being ‘Agile’ enough to respond to changing requirements. I felt we did a good job of this as we planned this event; allowing our processes to be fluid enough to deal with evolving scope and requirements – from speakers, venues, logistics and more.


Filed under Business, Events, Management, Marketing, Project Management

True Growth Hackathon. A brief re-cap (Update 1 of 3).

hack name tags

Reference the original post here:

As a loyal reader of my blog you’ll recall from my earlier post that I was working with Enterprise Saint John and some community volunteers to organize a Hackathon.

And organize a Hackathon we did! It was awesome!

The turnout was good and the level of engagement was tremendous. Through connecting the non-profit community with the ‘IT’ (developers, analysts, project managers, marketers and more) community (we had people from Saint John, Fredericton and even Prince Edward Island) we were able to come up with some pretty great ideas.

The ideas then lead to some brainstorming and product envisioning sessions that, a day and a half later, culminated in 3 working prototypes that the teams presented to a room full of creative and enthusiastic techies and non-techies and a panel of ‘judges’ that scored the teams on such things as working functionality, quality and innovation.

Everyone left with a prize, a handfull of new business cards/contacts, as well as a sense of excitement for the possibilities for the next Hackathon (tentatively envisioned for late spring/early Summer 2014; email me if you’re interested in getting on a mailing list for updates) and how these sorts of things really enhance Saint John as a destination for IT. (As validated – a short time after our Hackathon, no less – in this article in the Halifax Chronicle Herald where Saint John was selected as the ‘Best Community for Information Technology’)

Check out a few links about the Hackathon, the teams and the prototypes:

1 Comment

Filed under Events, Innovation, Project Management