Agile and the PMBOK From many sources both in and out of the PMI there is a general consensus that the PMI is moving toward a more flexible and agile-type project management philosophy. PMBOK version 4 has words throughout which reflect that tendency. However, the PMI and PMBOK are aimed at all project managers, not only IT project managers so explicit endorsement of agile software development mechanisms would be inappropriate since most of the practices only apply to software development. A lot of non-IT project management can only be done in a linear or waterfall fashion, such as construction. Even in IT many projects such as rewiring a facility for wireless connectivity or upgrading a server farm must be done in a phased approach. Projects other than software development that lend themselves to the iterative, agile approach include marketing programs, "soft" R&D, any project that includes artistic considerations such as web content development, annual reports, producing a movie or television show, mounting an art exhibition, etc. Basically any project where the outcome is not explicitly clear can benefit by applying some agile tenets of iteration and incremental delivery. Where the outcome is clear and the requirements are hard - say, a space shot or shuttle launch - linear, non-agile is much more applicable. The PMI must walk the tightrope between the two approaches to define general project management practices that apply to all so that the PMBOK doesn't have statements of condition, "In projects like this, do this, else in other projects do this other thing". Perhaps someday the PMI will produce two sets of PMBOKs  ¶ 2:30 PM 1 comments

  Knee Jerk Reaction We've been talking about Twitter and whether it is useful or not to IT folks, or anyone for that matter. Everything has a use, or it wouldn't be used. And not everything has a use by everyone or there wouldn't be so many different ways of doing things. So much for a disclaimer. I haven't quite got the hang of Twitter. I've tried. Since I don't have a Blackberry or other similar device, and I don't text on my cell phone, it being too tedious for me, perhaps I am one of those for whom Twitter is something other people do. There are several social concerns I have about it, though. Twitter contributes to the growing rudeness of adults - one expects a certain level of rudeness out of teenagers and younger children - who tweet instead of participating at a meeting, or even tweet while talking to you face to face. Taking a cell phone call during a meeting usually prompts apologies and some embarrassment and an explanation of "I've really got to get this" with more apologies after the call perhaps with an explanation of why it was so important. I don't hear anyone saying, "hold on, this Tweet is important. I'm sorry for the interruption."
Moreover, I'm concerned about the Knee Jerk Reaction effect. Even with Instant Messaging, which has the safety net of being aimed at only one person, there is a bit of consideration before placing hands to keyboard. And with email, blog postings, board and forum postings, etc. there is usually some thinking involved beforehand, and the opportunity to cancel a posting or email before it gets embarrassing. With Twitter it's all out there: your immediate thoughts: good, bad or something else. Reading some of the tweets, in my attempt to understand what it is all about, I see people whose opinions I respect and seek out, jotting banalities about arriving at an airport and seeing a long line at security, or looking forward to going to the office, or something.
The messages seem mostly prompted by boredom or simply the urge to reach out and touch someone during those lonely moments we all slide through every day.
The problem is that hundreds of people will read the message. If the message is a knee-jerk reaction to something that happens, an moment of anger perhaps, it's gone. The time it would take to compose and author an email usually is long enough for some consideration of what we are committing to posterity. Telling someone on the phone that you don't like a proposal that the VP is making during a break, out of earshot of the participants is one thing. Only the person on the other end hears you. And if the proposal turns out to be good, both parties may have forgotten the negativity, or a single explanation will suffice. When the same negative comments are on Twitter they are recorded and irrevocable. What you would not have said in an open forum, especially with the VP present, is now recorded for all to see, including the VP. Not having the ability to Twitter, or the inclination, might have allowed reason to prevail, and prevented the embarrassing moment when the VP asks why you didn't voice the objection in the meeting.
In IT we are slow, considered, reasoning, logical, and not known for our impetuousness at least when dealing with the tools of our trade. We plan before we test, design before or while we code, get some requirements before we design, think before taking actions. We spend a lot of time analyzing. This works better than popping off with our first impulse. I wonder how the impulsiveness of Twitter fits in with the IT culture. I also wonder what massive mistakes might be made when there appears to be a groundswell for some idea and it is merely the result of many knee-jerk reactions to an initial knee-jerk reaction that were reconsidered after tweeting. I see the possibility for a form of electronic group think. I also see the possibility for massive manipulation by marketers and others.  ¶ 5:47 PM 0 comments

  Project Planning It occurs to me that part of project planning matches the process of defining requirements. In requirements definition the business requirements, typically defined by the business analyst, define WHAT needs to be done to solve the business problem and the system requirements, typically defined by the systems analyst, define HOW the problem will be solved. In project planning the Work Breakdown Structure (WBS) defines what the project needs to do to solve the problem, and the precedence network, complete with critical path, defines how it is going to be done. The process of defining what needs to be done and then how to do it is not often followed nowadays as, in the rush to get things done to be competitive, often development teams simply rush to doing something without taking the time to really define what needs to be done and then how to do it. Plans are good. And requirements are really nothing but a plan to solve a problem.  ¶ 9:47 AM 0 comments