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.
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 visit here 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…