To people somewhat involved in projects - and who hasn't been - the word alone may bring up personal experiences and a general notion, well, most projects fail. HBR said so in 2003 (source) and ten years later, the situation appears not all that different, in academic research, and it seems to get worse, according to the Project Management Institute, who have solutions on offer and whose newest standard PMBOK5 adds a chapter on project stakeholder [engagement] management [addition mine].
Examining how I could accelerate innovation in the company, I saw the need to learn about professional project management. This is a story in two parts:
1. how, where and what I studied recently, and
2. what tools I picked up along the way work for me.
If you are into finding causes for project failures, here is a Google Search to get you started (4.6M hits, hey).
Before beginning, how I got here
My professional passion includes service, selling, and innovation. In small projects 25 years back, we were recognizing customer needs we could serve faster, cheaper, or easier to re-use and derive value from, by putting new technology to use. This kind of one, two, person skunkworks was part of enabling the company to grow in the region, fueled by customer demand and satisfaction, from 30 employees when I joined, to 3000 employees 20 years later. In the time of DOS on the PC, I ended up programming applications, buying equipment, and teaching colleagues. The methods spread. The last copy of some "app" of mine was in productive service for 10 years.
As we grew and built the network with head office in Germany and its global subsidiaries, I saw larger projects with larger risks. My career involved building the service and department for management system certification, authoring manuals for our own quality management system, helping the company join the UN Global Compact, and establishing the regional compliance officer network.
Beginning by the book
In short: A colleague was so kind to lend me his copy of Head First PMP. Mostly an easy read, good exam questions, but I did not find the tools I could apply to accelerate my jobs at hand.
Over a number of weekends, I worked through the book, understood the basics and the processes that professionals use to manage large projects, read up on the web and got the idea why the 44 process elements in 9 groups are useful and often worth the time invested into internal work like documenting requirements, approvals, change requests. The definitions contain hints why many projects fail. We are doing something new, for the first time ever, there is uncertainty in innovation.
Duh. Synapsing with angel investor experience: most startups fail, but the succeeding ones reward the risk takers and more than compensate for the losses.
The book helped me to decide I was not going for PMP certification. This was not because of the test, I learn new things every day and usually can apply them pretty rapidly; and not for project management experience, I could document 1500h. For my needs, the PMP certification would be a detour, nice to have but not essential. I was looking for tools beyond the book - tools, not descriptions - to bring quick wins and lasting benefits to the company and our Clients. The friendly colleague runs IT projects successfully, but being in Business Development I was looking for ways to get ad-hoc teams and Client service development projects worth a few months of work on the same page.
Why I became a student again
In short: Found BPM 101, signed up just in time and enjoyed Dan Clapper's easygoing, profound lectures, his well-workable material, textbook recommendation, and collaboration with the course participants.
There I was, electrical engineer, safety inspector, department builder of management system services, continual innovator and seeing more global projects, upcoming. In the annual personal dialog with a top executive, I added the self-development goal to learn professional PM.
To learn faster than by the book and gain pro insights to limitations and pitfallls of the various methods and tools, I booked a professional course, introduction to project management and went to Temple University on weekends.
Summary in six words or less: Learned a lot, using it already.
Course Textbook
The Fast Forward MBA in Project Management by Eric VerzuhLess focused on the PMP exam, and more on real-world examples, FFMBA helps get to the point, especially when you hear Dan in class adding his practical context and insight to selected chapters.
A few select comments and quotes I posted via amazon Kindle to facebook (currently the only one of two ways to share quotes, the other is twitter).
These quotes appear important after finishing the course and most of the book, but taken out of context as I do it here, may leave the impression the book is mostly about agile. It is not, it is mostly about waterfall and how to do it right, but it acknowledges the limitations.
As battle plans shatter upon first contact with the enemy, project plans need to be flexible, agile, emergent. Encourage gaps, track and regularly rearrange priorities. Here is why.
Emergent design is different from other approaches that focus on building full frameworks for the system and then filling them in. This does not work. It requires understanding the needs of the full system. And having to do full analysis defeats much of the power of the agile approach. Even if you could build a full framework, there is a trap waiting for you. If the framework meets the needs of release 1.0, what happens for release 2.0? Release 3.0? Release 10.0? No matter how well they are researched, frameworks that are built to handle a specific set of needs will eventually need to handle new requiements for which they were not designed. How much delay and wasted time did this involve?
Why agile delivers better quality.
In waterfall methods, testing the quality of the system is done at the end of construction. This means a lot of time is going to be spent finding and fixing errors, which is a poor approach to quality assurance. A better approach is to avoid errors in the first place. This is particularly important in avoiding the most common error in software: writing code that isn’t particularly useful. By some estimates, this accounts for as much as 64 percent of the features that are built.
Course Worksheets
On paper and in electronic form Dan shared excellent worksheets that methodically guide through important steps of learning. The key: getting to do a task, see for yourself how to get it right. In class he had time set for us to explain and discuss each other's work, leading to focused questions and broader insights in instants, where working alone with books may miss important points.
Using the worksheets, or with tools of our own choice, we had to turn in course work, Dan gave it back swiftly, graded with his checklist completed and helpful comments.
In class, I was using an actual project the company had started last year, that had fallen dormant, and rebuilt it following the exercises. I gained a new understanding of the big why and how, and worded a project change charter. Based on the groundwork done earlier detailed and built the key deliverable in a short time, fully reviewed against our corporate business conditions. Fortunately, our Sales already has Clients interested in the new service, so we could strike two PR-related deliverables from the work breakdown structure, enabling the team to complete the project within budget and on quality, even if not on time.
So far about the course, thanks to Dan Clapper and the co-students of BPM101 in 2013 Spring.
Next post will be about the tools.
Recent Comments