I wrote about ways to "cheat" at project prioritization [aka trying to figure out what to work on next, when there is more demand (projects) than supply (people to work on them)]. One significant tool you have at your disposal is controlling scope - can you do 20% of the work to get 80% of the benefits? Easier said than done, sometimes you need tactics, that help identify an opportune place to stop, a run-on project, or a design that…
Last time I talked about "cheating" at the PMO prioritization game. Ok, it wasn't cheating, more like a trick to keep your projects small, fast - and easy to fit into a crowded schedule. Totally above board, but some might call it manipulative. Remember the old management hack ... how do eat an elephant? If that's too cliche for you, let's talk about ways to consistently win at the prioritization game. How can you make sure your projects are legitimately…
Next year, our PMO will be taking a run at improving "transparency" for project prioritization - a clearer process for getting projects approved and scheduled. Here's a key building block - what is the most effective way to describe a project? There is a certain amount of art and style in getting this right; most PMOs feature some sort of central database listing candidate projects; typically, the various screens, views, reports, etc. are designed for "short and sweet" descriptions. Note…
Lots of conversation at work these days about PMO, resource prioritization, and reducing cycle time for IT projects. I feel a series of posts coming on ... IAPL, we launched a project to bring test discipline to our technology efforts. The team was writing standards and guidelines for test scripts, implementing integrated testing tools supplied by the ERP vendor, and adding steps to our project methodology requiring test scripts for all system changes. As the project dragged into a fourth…
via Slashdot a few weeks ago, and Ars Technica; at the University of Washington-Bothell, Martha Groom recently assigned her students to work on Wikipedia entries, and add to the knowledge base. An interesting approach; I found the reaction of the Wikipedia community most interesting, in that the entries were aggressively edited and commented upon - sometimes "rudely". It's a common theme in many KM discussions, as early adopters enter their first Trough of Disillusionment, and see these wonderful tools languish…
I'm following a project management meme lately; while freely admitting that I'm oversimplifying some complex topics, I will forge ahead with ... project "value". At work, we've been talking about the classic challenge of putting a business value on a project. I call it a "classic" challenge because it's a basic requirement for every prioritization exercise that I've been exposed to. You know the drill - we have 10 projects, but only time and resources to do 5. How does…
Okay, the title is a bit of a false advertising. I'm not revealing the top five rules - I'm actually looking for help in defining rules #3-5. Any input is appreciated - care to weigh in with an opinion? I've had a number of discussions, with some of the best project managers I know, as we discuss ways to simplify methodologies and streamline our delivery process. Many organizations are trying to train their next generation of project managers, and all…
My mother has always been an accomplished letter writer - her travelogues are definitely worth keeping. Lately, she's adapted her flair for the written word to email, having amassed a healthy mailing list of relatives, grandchildren, etc. Here's one she sent last month - I thought it was an interesting insight into the nature of learning. She's taking care of my aging grandmother, and writes ... ... when I was cleaning out mother's [room] ... I found a pile of…
Corporate Knowledge Management (KM) is hard. Hard to introduce, hard to teach/coach, hard to require, hard to create. Which, added all up together, often make it hard to use. It may sound like unfounded pessimism, as the Internet is loaded with examples of successful collaborative sites that aggregate and repackage knowledge - it's been doing that for years, ever since there were Compuserve forums and bulletin boards. Unfortunately (for the corporate environment), the Law of Large Numbers takes care of…
As I've noted in the past, it really helps to understand the techies' way of thinking, especially when trying to get work done on tasks that are decidedly non-technical. Here's two more recent stories from work, both hinging on the common desire to just "git'er done". Why do we waste time removing obsolete code? Just hide the menu option ... A few months ago, we had a task to decommission a chunk of code that was calculating some elapsed time information…