Driving Projects by Theory vs. Following Your Gut Feeling

By Chris Marr, PMP, CSM, PgMP, ITIL, Engagement Director

Your Personal Approach to Management

I think this is an interesting question, and depends on a lot of things; primarily, your approach to management/leadership in general, and also the types of books you read. I wouldn’t necessarily want to be on one of your IT projects if the book you call the PM Bible is in fact a book on gardening, or the J Crew Catalog (though you will be good for flower cuttings and very smartly dressed). Nor would I be thrilled to be your customer if you think cavalier is a conservative term for managers.

Now it’s useful to preface this with my views on project management. I look at each project as a start-up company, and each PM as an entrepreneur. So already you might guess that ‘by the book’ is not a term I live and breathe by, but I also have an engineering background so I do enjoy the theory stuff. That sounds like those perspectives are at odds with each other. Indeed as my wife would say, I am…odd. So let’s run with this and see where we end up.

PMBOK – Waterfall Methodology

Now by theory, I immediately think of the PMBOK, the traditional waterfall method, which is entirely different from Agile theory, or Scrum, RUP or anything else. But by the book is still by the book, but let’s agree for now the book is based on the waterfall methodology- I’ll then review this again from the iterative perspective. I start any project off with a certain element of theory – which for me is just common sense. You make sure you know (or define) your scope, budget and timeline, how the influencers are, your sponsors and stakeholders, and the team that will ultimately deliver whatever it is your project is destined to do. A solid Scope of Work, Project Schedule and Financials Breakdown are broad enough terms that everyone should understand them and no project should be without. On projects where there is high impact to the user community, a communication plan is also common sense. Similarly, Design Documents, Deployment Plans all have their rightful place in project artifacts that get us from a cunning idea in someone’s head, to something that I can touch, feel, smell etc. on Go Live Day, and a successful transition to Operations. That’s where I think theory has a strong play, and my hat off to the person that wrote the book and called this theory, when it really is common sense – Project Management is all about having the right person, in the right place at the right time, with the right tools. If that is theory, then I live and breathe it.

When Things Go Wrong

However, what happens when things go wrong? If you are thinking to yourself ‘things don’t go wrong on my project’ please use my UPS account to ship whatever it is you’re smoking, because I need some. Things go wrong on projects; it’s a guarantee, a bit like death and taxes. Consider a few scenarios – scope deviation; over-budget due to the need for some new servers or network switches, or your SME just went on a month sabbatical and you now have a junior developer covering for him…

Changing Design

The SOW is your bible throughout the project, it tells you what you should be doing and what you should not be doing for this project (design documents also drill down in to this detail), let’s assume you’re building a vacuum cleaner. Everything is looking good right up until your competitor comes out with an identical looking design right before you launch. Your business sponsor wants to go back to the drawing board, change the look and add an attachment that sucks up dust, dander and people’s egos. Now here, the SOW is invaluable – ‘it’s not in the SOW so now you can’t do this, without executing Change Control’ – two unfathomably important theory-borne instruments that a PM has access to. However, no amount of theory will change the fact that your scope is now invalidated by market changes. No Change Control document will help explain to your business sponsor why your project is on hold until they work out what to do. What is needed from a PM at this point is guidance. The PM has at his or her disposal the ability to present options – perhaps they can still release the vacuum cleaner and market as the #2 vacuum cleaner in its market, perhaps it’s technically more advanced and therefore better, perhaps going back to the drawing board is the right choice. Whatever the options are, the choice lies with the business sponsor, but they are highly charged and emotional at this point and need guidance and practical options. I don’t believe the chapter about being life-coach, mentor and visionary is covered in any PM theory book. It’s part of what I have spoken about before, the art form of Project Management. Reciting chapter and verse about scope management is not what will make the decision to turn this project around, or close it down, it’s merely a process that occurs once that decision is being made, but Project Management is infinitely more than process, it’s leadership – internally within your team, and externally to your customer and their customers.

Over-Budget

Let’s look at the second scenario, we are over-budget due to a design flaw we need to purchase a 22-gigawatt flux capacitor to make the system work. Now theory would dictate that you present your Change Control to the Customer and get their sign-off to acquire more funds. Let’s put some numbers to this – you have a $5M budget, and now you need another $1M to make the system work. That’s a 20% overage. While the Change Control is the mechanism to capture the approval or rejection, PM theory doesn’t tell you that to get approval on this will take a lot of hard work. You can’t expect a business sponsor to willingly sign-off without probing questions and a break down in trust if you hide behind an email or status meeting. Instead, this should be approached with care; building a relationship with your sponsor (or whoever it is you’re delivering a difficult message to) is paramount to the success of that message. Trust is as important as an SOW in a project. Without trust you are destined to fail, any relationship is.

Project Delay

With a project delay that is unexpected, the theory depicts the same – issue a new Project Schedule, identify it on the Issue Log, issue a Change Control to capture the acceptance of the new schedule – all these things are relevant, but are not necessarily going to be successful without putting is some legwork. A relationship where trust exists will allow you to pitch that you have analyzed possible scenarios (waiting until the SME returns, hiring a contractor etc.) and this is the best approach. A lack of trust will start with a shouting match (had a few too many of those!), and end up with a damaged relationship you need to spend additional time repairing. Now the opposite argument exists, that without this process or theory, a project is in a state of chaos, and you would be lucky to steer it in the right direction – this again comes back to your style of leadership. I thrive on chaos, I enjoy that start-up mentality, that lack of process but working with people who share a common goal, understand the confines, but are prepared to cross the lines on occasion to see where it takes them. Others will likely say that working in a structured fashion works well too and by no means are structured projects less likely to be successful or vice versa.

When things start to go a little crazy in a project, I leave behind the theory to get things back on track; it starts with conversation – not just when things get crazy but from the point when you start the project. I walk the floors and listen to others thoughts on where re-assigning resources will make sense, re-prioritizing work and so on. Collecting these thoughts from others I quickly weigh up each approach, or a combination of them and gut check them. Working with the tech leads we can do some scenario testing before presenting options and a recommendation to the sponsor. At this point, I likely haven’t checked my Earned Value, nor my communication plan, possibly not even my budget (though this will come soon). We are in ‘rescue mode’, for me the theory is not needed here, it didn’t prevent us from getting here and isn’t going to help get us out. Practical leadership, good communication skills and a peppering of luck will ensure we get out. Then I put my theory PM hat back on to track and capture what happened, what was decided and the approvers of the new plan.

Iterative Methodology

So let’s look at more iterative methodologies or frameworks. They inherently have less structure, to allow the iterations to be short and successful, and this lends itself more to the start-up analogy, it’s quick and flexible and allows decision to be made without the process that slows that decision making to a stop. A Scrum project takes a look at all the things you want in a product (the Product Backlog) and items get included in each release based on what will deliver the most value and what can be done with the available resources – it’s the exact fit for a startup – it can quickly react to a feature that didn’t work, or build on something that was successful. In my projects, I try to run them in this way, iterative and nimble, will still trying to satisfy the governance requirements that dictates a more waterfall approach – sometimes being a PM is a bit like being an illusionist – making people believe what they are seeing not what you are doing.

To recap, there is a place for theory, governance and such, but it doesn’t make a project successful; for me a project is successful when I deliver the widget that is needed, within budget and on-time even if I may not be 100% in compliance with an IT Governance strategy. In essence, I’d rather spend my time walking the floors, building trust than ticking a box, filling out paperwork or storing artifacts in a certain folder. I’d rather use a framework that allows for an iterative approach, is low on structure and process, and the team can dynamically choose to add more process or not when it makes sense to them, not because theory dictates it’s the way things are done. Reid Hoffman describes an entrepreneur as someone who will jump off a cliff and build a plane on the way down. It’s something that I also akin to a good Project Manager. To use my analogy of a start-up, I’d rather have a successful profitable business that is nimble and can respond to change in direction or market conditions than have a failure on my hands where I followed the ‘book’ but it didn’t work. Happy Project Managing.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.