A Brief Guide to A Guide to the Project Management Body of Knowledge   Leave a comment

I’ve reached a sort of clearing in the woods in my PMP studies this evening. It’s like I’m sitting on a fence mid-way between clueless and enlightenment. I’m so stoked! This is totally doable. I scheduled my test for late May just now. I thought I would celebrate my new-found optimism by giving a shout back over my shoulder about what it looks like on the other side of this here hill I’ve been climbing.

Note this is about the 4th edition; they just put out a 5th edition and PMP tests after July will use that. Also, I have not even looked at a practice exam yet. This is the guide to the guide, a premature book  report, not a guide to the test. Although other than the PMBOK I believe the only document covered is the PMI code of ethics, which as a new PMI member is a welcome addition and sub-set to my personal unwritten code of ethics. So, I won’t be linking to any pirated copies of the PMBOK out there… I swear the 4th ed. was available for free online from PMI. If I’m just not finding it, please link in the comments.

The guide is divided into 12 chapters and 7 appendices. In print it measures 8.5” x 11” x 1” at 467 pages. The first section is the Framework made up of two pretty dense chapters over 32 pages. That is all I managed to study from the day I cracked the book in early February to yesterday – granted that was between days-long gaming and coding binges (sabbaticals rule). And every time I slogged through a few paragraphs, I thought, “if the whole book is this dense, I’m gonna need a year to cram this into my head”… or give up Minecraft.

Then today I got to the second section, which strangely is just chapter 3 and my velocity jumped. It lays out WTF is up with the rest of the chapters. The PMBOK is primarily a system of 42 interlocking processes categorized into 5 groups and 9 knowledge areas. A diagram on page 42 brings it all together. 42 processes on page 42. Maybe the PMI is made up of Douglas Adams fans? Chapter 3 discusses the 5 groups and gives a condensed summary of each of the 42 processes. And then chapters 4 through 12 each cover a knowledge area and the processes in it, but in complete detail.

Each process has inputs and outputs. The outputs for some are the inputs for others linking them up. The 5 groups are chronological: Initiating, Planning, Executing, Monitoring/Controlling and Closing. The 9 knowledge areas are the 5 dimensions of project management I knew before: Scope, Time, Cost, Quality, and Human Resources, plus 4 more I had not considered as top-level dimensions: Communications, Risk, Procurement and Integration, the glue holding the other 8 areas together. The processes are very intuitive, familiar PM activities like “Define Scope” which is a process in the Planning group and the Scope Knowledge Area. It all looks very systematic and easily digestible.

So, I’m going to start really digging into each of those 42, but let’s look at some of those Framework concepts in the first section while we’re here…

The differences between project, program and portfolio management has always confused me. That could be because different organizations in software use these terms to mean slightly different things, but now I’ve got a standard to go by. Let’s see if I can make it any clearer (and see if I get it right, peers):

  • A project is a temporary endeavor undertaken to create a unique product, service or result. It has a beginning and an end. It has some inputs and some set of objectives that constitutes a successful conclusion. Examples would be a single release of a product or a recruiting drive.
  • A program is a set of projects related in some way that makes managing them in a coordinated way yield benefits you would not get if you kept them completely separate. Examples I can think of would be a group of products targeting the same industry or based on the same technology.
  • A portfolio is a set of projects and/or programs that are grouped together for some strategic business purpose. For example, I’ve worked at companies that had a products division and a consulting division who both ran software projects. Developers would sometimes transfer between them, and it was like going to work for an entirely different company.

The PMBOK also discusses sub-projects and phases. A sub-project is a discrete part of a project with its own input and objectives that contributes to the project’s objectives, but can be accomplished separately, perhaps by a sub-contractor. Phases are where you identify minor releases or waves of scope within a project that are minor or not discrete enough to warrant a sub-project. For both, you do initiating and closing processes, but with phases these activities are more of a retrospective and re-adjustment for the project.

It sure is a lot of Ps… Phase < sub-Project < Project < Program < Portfolio by Pmi for the Pmbok so I can get my PmP. So, something I’ve been thinking about is how this maps onto organizations and projects from my past. Or how Scrum maps to this; I mean aren’t Sprints basically phases? What do you think?

Posted March 16, 2013 by rosswright in Uncategorized

Why ROWE Sucks and How to Fix It   1 comment

Recently Best Buy and Yahoo have been in the news for bailing on their “work-at-home” policies. Best Buy was the birthplace of the Results-Only Work Environment movement and the book Why Work Sucks which I have been recommending to just about every fellow manager of people I’ve spoken with for a two years now.  Over those two years, I set ROWE policy and produced training materials for two incarnations of FrogSlayer. It’s been on my task list to do a ROWE-revisited blog because we implemented a ROWE and it bit us.

Disclaimer: the title is shameless attention grabbing. Sorry, I could not resist. ROWE doesn’t suck. Also, I  don’t  know how to fix it.

The main problem we ran into was management. ROWE requires more from managers. CultureRX and other ROWE-Kool-Aid drinkers would point out that the increased oversight of setting expectations and measuring results is something effective management needs to do anyway, and I agree. However, that doesn’t change the fact that it’s more work than just being a “hall monitor.” I can completely understand that if left to the management of Yahoo and Best Buy, they would vote to revert back to the old way – and they will continue to be just as ineffective and lose some good people in the process.

In our situation, our company grew both in business and headcount quickly over an 2-year period. We had more work than management, so for a time we had to put a lot of trust in our employees. And we were patting ourselves on the back a bit for implementing ROWE long before that. When things cooled off, we were pleased that the vast majority of our people buckled down and got it done when no one was looking. But, some did not. Thankfully, this was not visible to clients as the slack was pulled up by the non-slackers.

Some ROWE purists would probably cry for the slackers’ heads. The fact is sometimes talented, valuable people get lazy and without reinforcement they slip. I see ROWE as a libertarian philosophy; it brings freedom from stifling authority and can be effective, but it requires disciplinary measures I found lacking in altruism. I count myself as a libertarian, believer in ROWE philosophy… and also an altruist. So, I often find myself conflicted.

In the end, a few heads did roll, but the result was a re-emphasis on accountability. That included the kind of expectation setting and results measuring called for by ROWE philosophy, but also some presentee “all-hands-on-deck” thinking too: daily stand-up meetings, office hours, schedules, etc. Basically the worst of both worlds from the slacker employee point of view.

The feedback from our employees was largely positive; they craved more structure, more accountability from their co-workers. Presenteeism is not all evil; if an employee loses the discipline required to show up to work – that is a nice early warning to have. Just because you are required to come to work does not mean that the environment has to be a button-down sweat-shop cubical hell. Really, we may not have even strayed outside the boundaries of those possible workplace configurations that constitute ROWE-ness in our correction, but we definitely flirted with some big ROWE no-nos.

I’m glad to see the people at CultureRX have put out a follow-up book called Why Managing Sucks because that was my primary complaint about the first book; it was a call to arms for the “workers” with very little guidance for forward-thinking managers. We could not afford CultureRX’s consulting services, so we faked it and ran into problems. I’m sure a lot of other people are doing that too because CultureRX ain’t cheap, yo. Maybe this book will help; and if I ever manage people again, I’ll definitely give it a read!

So, the conclusions I am drawing here are:

  1. ROWE does not make work easier – not for the employees, and definitely not for managers. It makes fitting work into life easier, but work is still work and oversight is still oversight. If you stick to textbook ROWE, it makes dealing with employees that fail to deliver a much more difficult discussion as a manger or an owner. Especially if you’re in a field with hard-to-replace skilled workers like mine.
  2. When ROWE fails – especially if it is a lapse of oversight – it can fail silently and with great impact. It’s bad when people clock-in for 8 hours and only do 2 hours of work, sure. It’s worse when they don’t come in, stop working completely and you have a work environment philosophy that discourages asking them how they spend their time… so the situation doesn’t explode on you until you hit, or rather miss, a milestone.

So did I draw the right conclusions? Has anyone else has tried to implement or work in a ROWE and what have your results have been? This is a safe haven, no Kool-aid drinkers here, let’s hear it!

Posted March 12, 2013 by rosswright in Uncategorized

Learn to code   1 comment

My man, Brett Hlavinka, found a good one. Here’s the extended version…

When I was in elementary school in the 80s every school I went to from the ghetto schools of Seattle to the white-bread mountain-town of Arlington, Washington had Apple IIe’s for us to play with. They didn’t have teachers that could teach us to code very well, but they were working on it. And when I went to Junior High and High School in Texas, we had Apple IIs, Macs and IBM PCs – AND a great computer science  teacher.  And I kind of assumed it would progress from there to be ubiquitous. To find out that Computer Science is not even offered as part of every school curriculum in the 21st century is actually a bit of a shock to me.

This is a cause I can definitely get behind.

Posted February 28, 2013 by rosswright in Uncategorized

When to Roll Your Own   Leave a comment

(This is a re-post of a blog article I did long ago for FrogSlayer here)

When developing solutions for our clients, we have a vast array of third-party tools we can use to rapidly and efficiently develop software. The kind of third-party tools I’m talking about today are the GUI widget libraries and base toolkits that provide a higher level of functionality, such as those offered by DevExpress and Infragistics for .NET GUI development, or even pluggable CMS systems like Drupal or DotNetNuke for web sites.

We strive to reuse whenever it makes sense, but when does it not make sense? This is a tricky issue I deal with a lot.

The first thing I consider is how well the third-party tool matches the need. Third-party widgets almost never meet the needs of the solution right out of the box. They often require extensions to meet our requirements, but more often than you might think, the third-party developer has been so over-enthusiastic in adding functionality to their offering which we don’t need, that a significant part of our job is disabling and hiding needless complexity from the user! We must always weight the costs in time to roll our own code versus the cost for adapting the third-party tool. Often, building up what we need from zero is more cost effective than extending out and chiseling down a third-party solution to just what we need – without even considering other factors.

The second thing I consider is support. When we roll our own, we know how it works. It is custom-fit for our purpose and has no unknowns. When we use a third-party, the code is a black-box. Even if they supply source code, who has time to make sense of their pasta explosion? We are at the mercy of their developers’ abilities and the responsiveness of their support team. I have been burned enough by this over the years that I weigh this part of the equation pretty heavily. When things go wrong after the project is complete, clients get really impatient — and rightfully so. Saving a week of development time by using a third party that costs you a week of the client waiting on a fix post-implementation is not a trade you want to make, not if you value your client relationships.

There are probably a dozen other little issues I consider on this, but the last big one is the potential legal issues. We have clients that don’t want open source. They don’t want to monkey with redistributing code or GPLs or what-have-you. If they allow third-party tools at all, they want a very clear license granting unlimited rights and ownership. So, part of the conversation I have with clients at the onset is:

“Are you willing to leverage third-party libraries in your solution? What if they require re-distribution of source or a license?”

They have their own reasons, but even when we have a third-party tool that is a perfect match, some clients rather pay us to build a custom module.

And, honestly, that is fine with me. As a developer, I must admit I am biased toward building a custom solution. It is far more fun to build new than to hack old. Its not just me, every real code monkey I’ve worked with would rather write a new thing than adapt an old thing.Never underestimate the huge multiplicative effect on productivity of a motivated hacker – that also has to be factored into decisions on third party tools. And that gets factored into our bid.

At the end of the day, it comes down to solving the problem within schedule and budget, and sometimes the decision on whether or not to go with third party tools is counter-intuitive.

Posted April 6, 2011 by rosswright in Uncategorized