Friday, December 19, 2003

Process level agreements. The importance of taking a process perspective on computing is beginning to sink in. Jeff Schneider recently posted a ... [Loosely Coupled weblog] Comments6:49:03 PM

More on Contracting, Consulting, and being Independent. There have been some good posts on consulting and contracting lately.  These posts sort of form a thread, so I’ve arranged them in roughly chronological order. In his first consulting post, Rory breaks contractors down into two categories: headhunters or independents. Bryan then rants on the uselessness of headhunters.  The comments bring up some good points about the value headhunters do add. I highlighted DonXML’s comparison of consultants vs. contract programmers. DonXML talks about finding contracting jobs. In his follow-up post, Rory talks about the wonderful experience you can get being a contractor, as well as an understanding of the “metastuff.” Steve Eichert also pointed us to the “consulting tips from the million dollar consultant” web site.  In my opinion, the site is too full of self-aggrandizement, although there are a few good articles.  I’ve been reading about consulting, and the practicality of the blog posts is just awesome in comparison. Another good consulting site I check out is RealRates.com.  They have lots of survey data filled out by other consultants, so you can get a rough indication of what similar people are doing or earning right now. IT workers can also get the Robert Half Technology 2004 Salary Guide.  You fill out a form and they mail it to you for free.  Good for consultants or permanent employees.  I haven’t gotten any spam email or junk mail as a result of this, either.  Of course, I rarely get spam anymore. I wonder if the percentage of independents/contractors/consultants is higher for bloggers than it is for non-bloggers.  Anyone know or care to guess? [Darrell Norton's Blog] Comments6:48:12 PM

The Blind Leading the Blind. Thought you'd enjoy a taste of David Schmaltz's writing. David will be the first author we interview via a teleconference in January. Here David is writing in Winston Brill's Innovative Leader, The Blind Leading the Blind. David uses John Godfrey Saxe's famous fable "The Blind Men and the Elephant," as metaphor to explore the nature of projects and what we can do to produce success on our teams. (B)lindness is a continuing feature of work life today. Consider your last project. Didn't it require the enthusiastic contribution of several different specialists, each unavoidably blind to all but his own perspective? If your project succeeded, did the plan predict the path you ended up following? Chances are you succeeded by figuring out how to blindly lead each other to success, not by following some omniscient leader or predictive plan, but by somehow integrating the disparate perspectives of all of the "blind men." David offers six steps for dealing with the always-present blindness on project teams. What You Can Do to See the Elephant Be clear about your own purpose for engaging. Understand your intentions. Extend your trust. Let go of how it's supposed to be. Stop trying to motivate others. Sit in the mess before tidying it up. Visit his article to read how. We look forward to kicking off the New Year by having a conversation with David. You're all invited! Get ready by adding The Blind Men and the Elephant, Mastering Project Work to your wish list this holiday season. Better yet, buy two copies from Amazon. You'll get free shipping. You'll have one to give away and one to keep for yourself! Now, have a look at the announcement, http://leader.halmacomber.com/project_authors.html and follow the instructions you find there to stay informed. [Reforming Project Management] (sorry, none of my own thoughts, just tryingn to get this posted before i lose it). Comments6:47:20 PM

Selecting a Lifecycle. One of the most useful decisions a project manager can make at the beginning of the project is to choose a lifecycle for the project. Here's the way I think about lifecycles: Not every lifecycle is appropriate for every project. In fact, many lifecycles are inappropriate for many projects. If you can't determine the requirements fully at the beginning, don't use a waterfall. If you don't have a lot of time, plan to chunk the product, either with the chunking lifecycles or with the agile lifecycles. Test groups get into trouble when they think they can use a waterfall lifecycle. Most of the test groups I've met don't know the requirements before they start developing their tests, so I regularly recommend that the test groups choose a different lifecycle from the rest of the project. Sure, it's harder to integrate the milestones, but how else can you succeed? Think about what your customers think is important (time to market/release, feature set, defect levels). In what order does schedule, feature set, or defects matter to which of your customers? Then, review your risks. If you think you're going to learn a lot with this project, you have tremendous technical risk. If you know a lot about what you have to do, but the time is short, you have schedule risk. When you have both schedule and technical risk, consider using an agile lifecycle. If you have just schedule risk, consider a chunking lifecycle. For just technical risks, an iterative lifecycle. If you're an experienced project manager, you can divide up the project into several phases, each with it's own lifecycle (I once led a research phase using a spiral lifecycle, and then moved to design to schedule for the deliverable part of the project). No lifecycle is completely perfect, but each has possibilities for your project. Consider which lifecycles are most appropriate for your use on this project. [Managing Product Development] Comments6:45:53 PM

© Copyright 2005 Rebecca Schwoch. Last update: 2/8/2005; 2:15:12 PM.