Sponsored Links

jobs!

Online Chat

Use the window below to chat with me (if I'm online ...)

Use the edit nick field above to let me see your name.

cazh1: on Business, Information, and Technology

Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...

Wednesday, May 21, 2008

When is a project a Project? How to prevent the buildup of backlogged requests

When is a project a Project? How to prevent the buildup of backlogged requests

I just wrote something up (internal wiki) that I thought was common knowledge, but I think it's one of those soft-skills things that makes total sense once you hear about it - but somebody needs to tell you.

I think of one of the reasons that IT (at times) intimidates the business - or why IT gets the cold shoulder when it comes to process improvement efforts - is that we can get a bit too wrapped up in the Art and Science of Project Management. It's hard to build that business-savvy image when every new idea that comes your way is met with a 12-month waterfall Gantt, a copy of the PMBOK, and a formal sign-off sheet.

Howzabout a little common sense first? When you hear about an interesting idea from someone in the business, spend some face time with the requestor. E-mails and phone calls will not suffice; you can't build a relationship that way. Have a conversation about what they want vs. what they need ...

  • Sanity Check: Do they want something huge? Impossible? Impractical? is a great idea, but completely out of line with current corporate strategies/priorities? If so, help them understand they are boiling the ocean, it's overkill and/or not likely to get worked on in the next 12 months. If they agree that this is a bit of a stretch - hey, you're done! You've successfully stopped a bunch of needless administrivia work before it even started!
    • If they still think it's a great idea, consider capturing the magic by putting together a simple (i.e. quick) Project Charter document, and adding it to your "master list" of projects. Then, immediately put the project on Hold. It will be in your database / list forever, we won't lose track of the Great Ideas embedded within ... but it will be off of our immediate radar screen.
  • Training Issue: Are they asking for something that can be done in a different way (ie. shooting rabbits with a bazooka)? Maybe they don't understand all that (insert your favorite ERP here) has to offer. Can we solve their request with some training?
  • Quick Hit: If they're asking for something that is twenty effort hours (or less), has minimal impact on a small number of people (ie. no training will be needed), and could get taken care of over a few days/weeks - consider it "filler work", and don't bother creating a formal Project for the effort. The business will love that you're delivering value without bureaucracy. Your brain will relish the chance to fill-in the dead time between meetings. And, your boss will/should dig it because it's lagniappe - that little something extra. Sometimes, all they need is a report tweak or a simple data download ... Web 2.0 is not the answer for everything.
    • Caveat: Don't let this become the way that everything gets done. If a project is big enough, you should go through the proper level of rigor - it ensures that your efforts will be sustainable.
  • The Real Thing: Ok, if you've made it this far - this idea is good, it's not too small, will involve a number of IT and business resources that need coordination and communication - i.e. Project Management - then yes, you need to follow your IT group's standard process. No shortcuts (from here on out ...)

Previously ...

Technorati Tags: , , ,

Invisible Technorati Tags: , , , ,

Labels: , ,

posted by James P. MacLennan at 11:07 PM | Permalink | |

Tuesday, February 26, 2008

Butting In to the Conversation: PM Communication Tools

Butting In to the Conversation: PM Communication Tools

Dennis McDonald and Lee White are conducting an interesting experiment on their blogs, crossposting a conversation about project management and social media. I'll add my voice, with both input on the topic and observations on the method.

(Topic) The Right Tool for The Job - depends on the Job

The first part of the conversation talks about whether social media could replace classic project management tools, in terms of communicating project status. I agree with Dennis - you can never get rid of gantt charts, project budgets, and stoplight issue lists. It really depends on who the recipient of this information is; most of my project sponsors are busy executives who rose to the top in the era of e-mail and PowerPoints. Communication is uni-directional - you to them. Team members and external consultants, on the other hand, require bi-directional, collaborative tools, and most expect web-based environments accessible in and out of the corporate network, instant messaging for quick status checks, and blogs for general updates.

Truth be told, the most valuable tools in the project manager's communication kit is typically Ctrl+C and Ctrl+V.

(Topic) The Perfect Tool for The Job in Unlikely - but Opportunity Knocks ...

Another one of McDonald's posts lists features a wish list of features for the perfect collaboration environment. It reads like a feature list for MS SharePoint, and McDonald anticipates the reaction well (I, for one, welcome our new Comment overlord ... )

I KNOW that many of these features are already available in off the shelf products. Comments that are thinly disguised sales pitches without a sincere effort to contribute to this discussion will be mercilessly and gleefully deleted.

It must be that time of year - I've gotten a number of calls from vendors in the last few weeks, pushing any number of PMO environments that promise to manage my resources and solve all my prioritization woes. In these times of tight IT budgets, capital investment for new software like this rare - the dollars are better spent supporting the business.

However, all is not lost. The collaboration requirements of most PMOs can be delivered quite nicely with a collection of FOSS tools, MS Office automation, and a little ingenuity. Looking for a low risk project to throw at aspiring web 2.0 technicians and Millennials suffering from wanderlust? How about those developers trying to learn what makes effective user interfaces?

Every PMO I've ever worked with / built up relied all or in part on locally developed tools; the cobbler's children can usually hack up something serviceable. And to borrow a phrase from Lee White - most of the skills for project management and collaboration comes from creating the tools, not having the tools.

(Method) Not the Right Tool for the Job

I'm not sure I fully understand the technology that Dennis has used to combine the text from these blogs, as well as everyone's comments. My first reaction on reviewing the feed was less than positive; like a typical blog feed, it probably puts the most recent entry first - so if you want to follow the conversation, you must jump to the end of the list and page backwards. Of course, once I dove into the content, I got a bit lost. I'm not exactly sure of the order of the items in the feed, but best I can tell, the conversation starts in the middle and then sort of bounces around.

Discussion forum software does better at this task. The start of the conversation appears first; as I move down the page, I can scan the main conversation thread as well as any branches from the comments.

That's the other challenge with this method of capturing and displaying a conversation. There are a number of interesting comments, but I can't figure out how to comment on the comment, nor can I figure out how to add another voice to the conversation.

I've written about this previously; the best tool for the job depends on the type of collaboration you are trying to initiate ...

  1. Use an Announcement to make a statement, inform of an event, where you expect no comments or replies. The flow of information is in one direction only - out from you to the readers of the web page.
  2. Use a Blog to make an observation, deliver a status update - capture a well-formed thought. One or two folks may have question or want to add a follow up, but in general you expect a few comments at most.
  3. Use a Discussion Forum when you are asking a question, making a proposal, or establishing a new standard. Here, we expect a lot of discourse, with threaded conversations and branches and such.
  4. Use a Wiki when you are making a statement / documenting a fact. You should expect refinements, additions, and other edits - but not full-on discussions.
Authors Note: I officially despise ecto at this time. This is the second time that I've written this post - spent an hour and a half on it last night, only to have ecto mysteriously delete my work. I'm switching back to w.bloggar for now - gave up on it a long time ago, but it appears to have gone through some pretty extensive improvements.
Previously ...

Technorati Tags: , , , , , ,

Labels: , , , , ,

posted by James P. MacLennan at 10:00 PM | Permalink | |

Monday, February 18, 2008

Rules of Golf - Project Prioritization Process Needs Clear Documentation

Success, Failure, and Insights after 12 Months of Internal Web 2.0

Different areas of our IT department are using internal blogs, wikis, and collaboration spaces, with varying degrees of participation, readership, and success. Some observations:

Blogging is Easy ...

The blogs and wiki(s) have effectively removed the hassles of capturing and distributing information quickly. One important early decision was to not implement an editorial approval process for the wiki, and most blogs are wide open for public comments. No more excuses or complaints about a lack of documentation; if the explanation is not clear, or needs examples to make it relevant to multiple situations - all are fully empowered to fix it.

Some find the blog to be an easier way of communicating because of the "immediacy" - a sudden insight or pithy observation pops in your head, so you jump on the blog and capture the thought. These are the folks that have had a little insight, and gone beyond the idea of blogs as just an electronic replacement for a weekly status report. It might be difficult if you feel an obligation to say something every day - but if you really understand what you can and should be writing about, you'll probably make multiple entries every day.

... but Empathizing (with the reader) is Difficult

I still get pushback on the blogs - even among the groups that are currently our "best demonstrated practitioners". These folks are generating a decent amount of participation and content - but still not quite enough stuff to be effective. The challenge, it seems, is to get folks to empathize with the reader - a skill that I'm surprised more folks don't have, because many like to complain about what they don't know, or should know, or wish they knew.

Always ask yourself, what did I do or learn today that others would find interesting? No, it's not that the world wants to understand how my day went, or how I'm feeling. But I like to hear when people are starting (or stopping!) projects, or attending meetings and learning about events or decisions that may have an impact on my my work over the next three months. Empathize with your [potential] readers, anticipate their interest, and practice what I call the "beneficial assumption" ...

  • Most people think the same way I do ...
  • ... so I will anticipate what I'd like to hear about my organization, my projects, and my meetings ...
  • ... and write about that

Self-Policing the Content

What about stuff that [possibly] doesn't belong in a blog - even though it's internal? Key thing is to use common sense; the blog entry is just as permanent, and much more public, than an e-mail. Especially when it comes to "negative events'; sometimes the specifics aren't really relevant and don't add much value. Specifics, like somebody made a fat-finger mistake and deleted some data, or opened a hole in the firewall, or copied the wrong file. A blog is typically not a root-cause, problem analysis tool ... it's a general FYI platform, and specifics (especially the negative ones) moght be taken out of context by the readers.

Of course, we note that content should not be limited to all that is sweetness and light. There's nothing wrong with fact-based bad news, but there's a lot wrong with bad news that no one finds out about and then gets worse, or no one learns from. We don't write about this stuff to get folks in trouble, but we definitely do it to prepare, inform and educate.

Communicating is Still an Art

Some folks will rattle on in too much detail, while others are too terse. The fundamental challenge - most folks can write acceptably, but may feel they can't write well - they lack the confidence to capture it on paper. Confidence is something that comes with practice, but mandating participation is not going to encourage spontaneous composition.

Where Are the Comments?

Some folks surprise themselves with a good blog entry, and then become doubly surprised when then get no comments. Bloggers in a closed community / internal blog can't judge themsleves based on numbers and responses that you mgiht see on the Internet - heck, it's taken me two years to get up to about 50 subscribers to my feed [feel free to subscribe, dear reader!].

Previously ...

Technorati Tags: , , ,

Labels: , , , ,

posted by James P. MacLennan at 10:17 PM | Permalink | |

Sunday, February 10, 2008

Do you want it good or fast? Prioritizing Time-to-Value over Requirements

Do you want it good or fast? Prioritizing Time-to-Value over Requirements

I have a background in software product development, iterative "methodologies", and the sort of fast-twitch life cycle that characterizes entrepreneurial startups, high-growing businesses, and "lean" process improvement projects. Unfortunately, this style is also favored by departmental developer wannabes, sloppy coders, and impatient Gen-Y newbies that want to apply a consumer products mentality to corporate IT.

<aside>Yes, I'm throwing a bit of a challenge out with that last statement. I understand that as the demographics of my IT team changes, management style must change as well. However, notwithstanding CIO Magazine's recent deluge of articles urging oldies like me to "get with it", and embrace Web 2.0 flexibility, there are certain immutable facts that fly in the face of the recent college graduates urged to apply social networking, text messaging, and torrent-enabled IP sharing to the 9-to-5 grind ... but I'll save that for a later post ... </aside>

The real challenge is understanding how to introduce this new and different way of thinking (about projects and project delivery) into an environment rooted in audits and controls, waterfall methodologies, and tightly integrated ERP. Nothing wrong with any of these - in fact, for work in and around your run-the-business systems, there's nothing more comforting than the rigor of requirements, testing, and a controlled promotion process.

Still, many organizations focus on the wrong legs of the Iron Triangle. Let's assume that budget, if not absolutely fixed, is at least severely constrained (again, we're not talking about a fast growth company that has money to burn). At this point, the typical IT department - laboring under the twin misconceptions that the customer is always right, and the business understands the difference between wants and needs - dutifully captures all requirements, and work commences until there is nothing left to do. With budget and requirements "fixed", time is the variable, and projects go on for months.

I don't mean to sound cynical - sometimes it's not a question of kitchen sink requirements (as in, "everything but the ..."). Feature creep can also set in when folks want to develop code to test for every scenario or use-case. Even something as simple as adding type codes for a given transaction; believing in the power of metrics, folks will come up with a descriptor for every conceivable exception - regardless of the frequency or relevance.

I think the biggest difference between these organizations and their iterative brethren - startups, fast-growth, and "lean" organizations - is a focus on time to value. Established companies have predictable sales cycles, quarterly statements, and six month planning horizons; it's not about speed, it's about getting it right.

Established companies start to struggle with time to value when their environment changes. This is when a subtle change in project management style can go a long way towards liberating the locked-in value of these powerful organizations. Focus on that third leg of the triangle, and learn how to manage a project to a date. I have to be done in 60 days - what can I get done in that much time?

Sometimes this leads to a counterintuitive decision. For example, a make-to-stock company may have established a Microsoft standard for desktop systems, but a new line of custom engineered, make-to-order products may need to hire in a team of Macintosh-wielding product designers that must be productive on Day 1. In the long run, I may need to replace their new workstations, but I'm certainly not going to slow down the launch of a profitable new line while my standards team goes through a lengthy RFP and vetting process.

Another common mistake - or maybe a defensive mechanism for those well-grounded in the status quo. Sometimes people “give up” on the idea of getting projects done in a short amount of time – “nothing happens quickly here”. I maintain that we give up on the idea of getting it done quickly, because we're not giving up on the demand for 100% requirements. If we insist that the work must be done in 60 days, we will have to give up some of the nice-to-haves.

This is the big change management challenge before us - prioritize time to value over requirements, and focus on the 20% of the work that will deliver 80% of the value.

Previously:

Technorati Tags: , , ,

Labels: , ,

posted by James P. MacLennan at 9:43 PM | Permalink | |

Sunday, January 20, 2008

Update on Blogs as PM Tools - Tales from the Front Lines

Update on Blogs as PM Tools - Tales from the Front Lines

We seem to be going through a second wave of focus (hype?) in the popular technology press, on the idea of using blogs as an important project management tool. The topic made the cover of CIO Magazine this week - Lynch made a number of interesting observations - interesting because I don't necessarily see the same things in practice:

  • The Reputation Hurdle: While I agree that blogs aren't fully understood by everyone, the folks that need to use them pick up on the concept very quickly. The beneficiaries of project-focused blogs are the folks participating directly on the project, plus other teams that are dependent on the resources or results involved. We still need to present project status to the management level using tried-and-true PowerPoints.
  • Start Small: The biggest reason to start small, and allow the popularity of PM blogs to spread virally, is that you don't have to devote time and energy to develop training material. Folks see how blogs work, eliminating e-mail threads that clutter up their inboxes, and they just get their neighbor to show them how it works. The real power in gras-roots process improvement like this: you don't have to invest in formal training. Time-pressed IT departments typically don't have time to develop fancy training material - and they usually not good at it.
  • Curing the eMail Addicts: Lynch opens up a very interesting door when he connects importance of RSS to the relevance of blogs. I've had a couple of conversations now with folks who can only see blogs as yet another website I need to visit, more information overload to deal with. eMail is a mission-critical system for many companies, partially because people have learned to use it as an information aggregator. Only when folks see an RSS client in action do they really understand what's going on; the blog/website is nothing, but collecting feeds from the 50 projects you want to keep tabs on, and seeing timely updates about them all in one place - that's powerful, and that's when they really "get it".

A Key Observation

We've been using the MS SharePoint template for a couple of different projects (single efforts) and programs (groups of projects in support of a strategic initiative). We've also had an IT wiki in place for almost two years now. It's fascinating to note how different the rate of adoption for these two technologies has been; getting content added to the wiki is sometimes like pulling teeth, but the blogs are taking off in some areas. Even in small teams that sit within 20 feet of each other; postings, comments and responses are plentiful.

After talking with some of these folks, I've realized that using a blog and responding to a post is just like eMail - it's just stored in a database, accessed using the browser, and conveniently linked to the project. The wiki, on the other hand, is Yet Another piece of formal documentation - and who likes to do that?

More and Better Thoughts

I had a few posts on this topic last year, but Dennis McDonald has been consistently posting a bunch of interesting content in this area:

Previously …

Labels: , , , , ,

posted by James P. MacLennan at 10:28 PM | Permalink | |

Monday, January 14, 2008

Three Business-Case Arguments for Agile, & The Moose On The Table

Three Business-Case Arguments for Agile, & The Moose On The Table

Another conversation at the start of the new year - this time in our PMO, concerning project prioritization and resource assignments. Many organizations follow a "parallel" model, launching multiple projects at any one time and working concurrently to move things forward. To be fair, this often occurs because we start work on one or two things, only to have additional worthy business requirements pop-up as time goes by. Unfortunately, we don't stop the first project or delay the second; most teams attempt (with mixed success) to keep multiple plates spinning at the same time. This certainly feels less-than-optimal; stuff gets done, but it seems to take more time than one might expect.

Here's a simplified example; say I'm working on four projects at once, but I'm spreading my effort across them all:

As this picture shows, all the projects take a year to finish; note that none of these efforts deliver any value until they're finished. Resources are dedicated to the projects using the given percentages; I'm dedicating 25% of my time to each of these efforts.

An alternative, of course, is to work on projects serially; finish the first project before you start the second, and so on ...

There are a number of significant benefits to the latter approach - benefits that are easy to put in business terms:

  • Higher NPV: Working in parallel mode, none of the projects deliver value until the end of month 12. In serial mode, the first project starts to deliver value in month 3, the second in month 6, and so on. From a cash flow perspective, the NPV of Mode 2 is much greater than Mode 1; this is something most business people grasp immediately.
  • Focus leads to Speed and Quality: Possibly an oversimplification, but it seems apparent that if I'm only working on one project at a time, I am wholly focused on that effort, and I can drive to "done" faster. In Mode 1, my attention is diluted as I flip between any number of projects.
  • Business Agility: For most teams, once you start a project, it's hard to stop. When I launch multiple projects as in Mode 1, I get "trapped" into trying to finish everything over the course of the 12 months. It becomes very tough for me to adjust my business priorities, react to changes in the competitive environment. On the other hand , if I work the projects in serial fashion, I can take advantages of the breaks between projects to re-evaluate and adjust priorities, refocus efforts on Project 1004, say, earlier than planned if that's where the most value is.

Yes, it's an overly simplified picture, but those are three pretty good business-oriented reasons to shift project teams to working on one thing at a time. The same logic applies to the various Agile methodologies, with short-duration, staged deliverables, shorter time-to-value, and the ability to reprioritize as you go.

I think the biggest reason why most organizations don't do it this way is the "moose on the table", the uncomfortable truth that everyone knows about but no one wants to deal with. Mode 2 is more confrontational; to start the cycle, you're going to have to tell three people (project sponsors for 1002, 1003, and 1004) that their project doesn't prioritize as high as 1001. Human nature, especially in the corporate world, leads us to avoid confrontation - but that's too bad.

... To get maximum benefit, you're going to have to disappoint the majority of your project sponsors - but only for the short term.

... The business likes to see something happening - any activity, even limited to 25% of my focus is "better than nothing" - but that's taking a very narrow focus.

When folks step back and look at the bigger picture, the business benefits of working on fewer projects at any one time jump out at you. Still, it's a tough conversation to have ...

If it was easy, you'd be doing it already, right?

Previously:

Technorati Tags: , , ,

Labels: , , ,

posted by James P. MacLennan at 10:51 PM | Permalink | |

Monday, January 07, 2008

Five Simple Rules for Project Names, plus Four Sample Lists

Five Simple Rules for Project Names, plus Four Sample Lists

A recent post by Jeff Atwood about project names brought back memories of a previous employer, and the project naming convention we set up in our PMO. At this company, the IT group spawned maybe 30 to 50 chunks of work we would call "projects" - at least two calendar weeks in duration (anything smaller than that was just a programming request, and given a control number).

Like any good PMO, we generated charters, mission statements, requirements, process maps, status reports - many deliverables. These projects can go on for weeks (if not months), and often become part of the vocabulary of the organization (are you going to finish "Falcon" in time for the requirements phase of "Hawk"?)

I got introduced to "code names" in the business world when I was with a corporate strategy group in the pharmaceutical industry. As a public company, you couldn't risk information about potential business partners getting out prematurely, so all presentations were loaded with mysterious references to the product families and market positions of Piccolo, Harp, and Drum. It sounded fun, so I picked up the habit for my next PMO.

At the end of the year, a key task for the PMO was to come up with a list of names for projects in the following year. We changed the theme of the lists to get a little variety, and also to reinforce the need for continual change. Of course, technical people can have a vicious wit, and any effort - no matter how worthy - can be torpedoed if the project name has any sort of negative connotation (who wants wants to work for Project Sloth?). So over time, we developed a short list of guidelines for project names:

  1. Single Words Only: Some file systems don't like files names with spaces in them. If the names could later get applied to servers, folders or other objects in a directory, spaces might give you trouble there, too.
  2. Not Too Long, Not To Short: A decent name should have more than 5 letters, less than 10.
  3. Three Syllables or Less: Need to be able to say it quickly - it's shorthand, remember?
  4. Avoid Easy Jokes: If a marginally cynical person could see something crude, childish, or even mildly offputting in a name - just skip it. The instant the project gets into the slightest trouble, the jokes will start.
  5. Use Names in Moderation: if your PMO generates over a hundred projects in a single year, skip the names and just go with a simple numbering system. Referring to Project 8053 is just as good of a shorthand as Project Condor. Consider using names for groups of projects (programs?).

Here are some examples of good project names; note my favorite topic, Music. I always liked to be part of any project called Drum - not sure why, just sounds cool ...

Music

ACCORDION, BAGPIPE, BANJO, BASS, BELL, CELLO, CHANTER, CLARINET, CORNET, CYMBAL, DRONE, DRUM, DULCIMER, FIDDLE, FIFE, FLUTE, GUITAR, HARP, MANDOLIN, OBOE, PIANO, PICCOLO, RECORDER, SNARE, TIMPANI, TRUMPET, TUBA, VIOLA, VIOLIN

Birds

ACCENTOR, AVOCET, BECARD, BLACKBIRD, BLUEBIRD, BOBOLINK, BRAMBLING, BUNTING, CARDINAL, CATBIRD, CHUKAR, CONDOR, CORMORANT, DOVE, DUNLIN, EAGLE, EIDER, FALCON, FINCH, FLAMINGO, FLICKER, FULMAR, GANNET, GOLDFINCH, GOSHAWK, GRACKLE, GREBE, GROSBEAK, GULL, HARRIER, HAWK, HERON, JAEGER, KESTREL, KINGBIRD, KINGFISHER, KINGLET, LONGSPUR, MAGPIE, MALLARD, MARTIN, MERGANSER, MURRE, NIGHTJAR, ORIOLE, PARAKEET, PARROT, PINTAIL, PIPIT, PLOVER, QUAIL, RAIL, RAPTOR, RAVEN, REDSTART, ROADRUNNER, ROBIN, SANDPIPER, SHRIKE, SPARROW, STARLING, STORK, SWAN, SWIFT, TANAGER, THRUSH, TOUCAN, VERDIN, VIREO, VULTURE, WAGTAIL, WARBLER, WAXWING, WEAVER, WOODSTAR, WREN

Fish

AHI, ALBACORE, AMBERJACK, ANGLER, ARANA, BARRACUDA, BERGALL, BLUEBACK, BLUEGILL, BLUEMARLIN, BLUERUNNER, BONITO, BREAM, BRILL, CAPELAN, CARP, CAVALLA CHARR, CINOSA, COHO, CONGER, CORBINA, CREVALLA, DOLPHIN, DORADO, EEL, ESPADON, EXOCET, FORELLE, GALLINETA, GOLDEYE, GRENADIER, HADDOCK, HAKE, HALIBUT, HAMMERHEAD, KALMAR, LEMONSOLE, LONGFIN, MACHETE, MANTA, MERLANO, MINNOW, MORAY, MURENE, OYSTER, PALERO, PALOMETA, PASSERA, PERCH, PERLON PERSICO, PETRALE, PICKEREL, PIKE, PILCHARD, PINBASS, POMPANO, QUILLBACK, ROCKFISH, RUMBLEFISH, SABLEFISH, SALMON, SANDDAB, SEABASS, SEAHORSE, SEAROBIN, SHARK, SILVERSIDE, SKATE, SKIPJACK, STRIPER, SUNDIAL, SWORDFISH, TARPON, TIBURONE, TIGERSHARK, TONG, TORO, TRIGGERFISH, TROUT, TUNA, WALLEYE, YELLOWFIN

Islands

ALLEN, ARCH, ARROWHEAD, AUDUBON, AUGUSTINE, BAKER, BALLAST, BANKS, BARTLETT, BARTON, BATTLESHIP, BAYONET, BLOCK, BLYTHE, BOCK, BRANT, BREWSTER, BRIGGS, BROOKS, BUFFALO, BURNHAM, BURRIS, CALYPSO, CAMPBELL, CANARY, CARROLL, CARSON, CASCADE, CASTLE, CATHEDRAL, CEDAR, CHANNEL, CHAPMAN, CHESHIRE, CHIMNEY, CLEVELAND, CORONADO, CRICKET, CYPRESS, DEARBORN, DIAMOND, DUCHESS, ELK, EMERSON, ESKIMO, FENIMORE, FLATTOP, FORBES, FROST, GARDEN, GOULD, GOVERNOR, GRAND, GRANITE, GRAY, GREENWICH, GRIFFITH, HAMILTON, HARBOR, HAYSTACK, HICKORY, HUNTER, HYDRA, ICEPLANT, INTERLAKE, IROQUOIS, JORDAN, KELLOGG, KETTLE, KIMBALL, KIRIEN, LANGLEY, LARKIN, LASALLE, LIMESTONE, LINCOLN, LITTLEFIELD, LIVINGSTON, MAPLE, MARINE, MASON, MILLIKEN, MITCHELL, MONUMENT, MORSE, NAVY, NESBITT, ONARI, OREGON, ORION, ORMED, PALMYRA, PHELPS, PINNACLE, PORTAGE, POWELL, RAINBOW, RAMSEY, ROSSITER, SAIL, SAWYER, SCOUT, SENTRY, SIGNAL, SLATE, SPAR, SPINNAKER, SUGARLOAF, SYRACUSE, TAHOE, TALBOT, TAYLOR, TEEL, TERRACE, THATCH, THORNE, TIKI, TILDEN, TOGARI, TONGA, TORRY, TRAVERSE, TREASURE, VENTURA, WASHBURN, WHALEN, WILLOW, WINDMILL, WINONA, WOLCOTT, YORK

Technorati Tags: ,

Labels: ,

posted by James P. MacLennan at 11:19 PM | Permalink | |

Saturday, January 05, 2008

Tactics for Controlling Project Scope

Tactics for Controlling Project Scope

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 is"simple enough".

  • Apply the Law of Diminishing Returns "in reverse", and front load the benefits. Let's say we're implementing a series of components (people, process, and technology) to analyze and improve promotion response. If I really understand the ROI, can I break it up into chunks? In this case, you might see a basic software package that defines master data, collects transactions, and provides basic metrics for promotion response. Let's say this visibility allows you to realize 70-80% of the benefits, but we want to follow with "phase 2" where we add training, tuning, and optimization to get another 20 to 30% of your ROI. Well, time and resources are short - why not stop at phase 1, let the new processes soak in, and "optimize" later?
  • Eliminate the 90-percent Done game - Projects that run-on forever sap the energy out of your teams, and destroy credibility with the business units whose projects are getting delayed. Via Vinson, here's an excellent post from Blain that reference's Zeno's Paradox (I'll never get there if I keep traveling half of the remaining distance ...). The primary tactic is to define discrete deliverables (tasks?) and only accept a binary status - it's either done or it ain't!
  • Keep It Simple, Sir! Feature creep is the greatest enemy of the short-term project. Some features (like quality / testing) are not what you'd want to negotiate out of the project. Thinking about cutting short on documentation? You naughty, normal person ... However, take a look at this post from Sierra, with a great illustration of the idea that usability is optimized right before the user has to reach for the manual!

Click on the picture for a full-size image!

The folks at Big Contacts liked the idea so much, they tout it as a feature ...

With Big Contacts there is no user manual. Because once you create a user manual, you are admitting your application is too difficult and that people need a book to use it.

Let's steal that idea for our projects. No documentation required, because the deliverables (process, technology) are simple and common sense enough that people don't need a manual, a training class, etc.

Ok, maybe it's not "practical", but it's a Worthy Goal that could help keep scope down to a dull roar ...

Previously ...

Technorati Tags: , , , , ,

Labels: , , , ,

posted by James P. MacLennan at 12:36 AM | Permalink | |

Thursday, October 27, 2005

Subdivide a huge project list to simplify the prioritization process

Subdivide a huge project list to simplify the prioritization process

A classic problem for many project-oriented organizations (IT, R&D, Engineering, Operations) ... how can resource prioritization be simplified, yet repeatable? It's a fairly involved topic, but a common approach is to group projects into a workable number of "chunks" ... we'll use the term Initiatives. How will this help?

Challenge: Clarify the team's priorities, alignment, and resource levels - without going into the details

  • The CEO asks a question – what Projects are on the to-do list for IT? [Do we actually expect the CIO to review 300+, or the (current) top 20 of a fairly fluid list?]
  • Top tier of [insert business unit] asks [insert IT director] to break out IT spend / allocation against Projects / Priorities – on a single Powerpoint slide
  • The Finance team wants us to allocate next year's budget across “projects”, somebody suggests calling out the business' Key Projects – but that list will be outdated in a few weeks

Solution: Group all projects into Initiatives, and use this list to identify / prioritize / categorize new and existing work

Ok, this seems kind of obvious, but managing an ongoing list of projects and initiatives is a bit of a hassle - you'll need to deal with

  • Fluidity – at the project level, the current #1 priority / “gun to the head” can and will change week to week
  • Detail – Work always expands to fill a perceived vacuum, and you can easily anticipate a "backlog" or oversupply of project ideas that could stretch out 2 years or more
  • Noise – Expect a lot of “noise” in the detail, especially if you're taking on an existing backlog; you'll see project requests that stretch back months and years, with names of Leads, Sponsors, and Requestors that are no longer with your organization

The Initiatives approach should help with all of these - especially in the beginning stages, when you are laboring to remove most of that old "noise" in the system.

Key Question: How do we identify an Initiative? Here are two simple rules

  1. If the work / projects underneath can aggregate to at least 10% of the total ($$, LOE, revenue, whatever) – it’s an Initiative
  2. If it’s a bullet point on a slide for the CEO or the BoD – it’s an Initiative

Rule 2 is pretty important to understand - it's your first simplistic hack at tying project prioritization to business strategy / corporate goals. Don't be too cynical about this approach; the sound bites that appear on executive radar screens may change every qurter, but if you are eventually communicating with those folks for go/no go approval, capital / expense or people resources, you better make sure they can draw a straight line between a given project and their current hot buttons.

Ok, so with that premise, here's a starter set of of Initiatives that are generic enough to work in most organizations. The first ones are for general business projects ...

  • Compliance: Includes mandatory work due to regulatory, audit, and/or vendor requirements
  • Procurement: Streamline and standardize procurement to realize savings on Direct and Indirect spend
  • Cost Reduction: Drive hard-dollar cost reductions through improved process and use of technology
  • Maintenance of Business: Includes mandatory work due to customer demands, plus value-add work to enhance customer realitionship. No hard-dollar revenue impact, except when preventing a loss of business
  • Productivity: Drive soft-dollar cost reductions through improved process and use of technology
  • Growth: Enable and support hard-dollar, top-line revenue growth

Note the focus on hard-dollar benefits. This is a philosophy/guideline, not a rule; your organization or your management style may allow for soft-dollar benefits in project justifications. Also, the list is sorted from things you have to do, to things you could/should be doing.

These next ones are for IT / technical projects; you need to make the point that a crertain amount of the IT departments' time should be spent on IT-focused projects (investment work) ...

  • Business Continuity: Foundational work required to keep the business technology operating
  • Maintaining Currency: Drive down long-term cost of ownership by maintaining technology at a pace with vendor and environmental advances
  • Technology R&D: Frontier work to evaluate and operationalize new information technology to support business goals

Yes, these are all generic Initiatives - no examples of Rule 2 (above), since that will be organization-specific. The key is to make the list of reasonable length, assign projects to initiatives, and present the aggregate totals when discussing prioritization

"... our resources are distributed across 20% Compliance, 40% Maintenance of Business, 30% Cost Reduction, and 10% Growth projects"

"Sounds great!"

(or)

"Goodness, we need more growth - can we dial back on the maintenance projects?"

Now that is a very simple, meaningful, relevant conversation to have with an exec.

Labels: , , ,

posted by James P. MacLennan at 8:20 PM | Permalink | |