Update: This post refers to the concept of a failing project, not any particular project.
No, I didn’t misspell the title. I am trying to convey the horrendous nature of watching a project hurl itself into failure. I’ve been hired by management several times to reverse a failing project. My optimism about being able to rescue a project from hell quickly fades on that first day.
No users involved in the project – We don’t need no stinkin users.
Scope of project is off – We aren’t quite sure what we’re making.
Poor Change Management – Oh they just tell us what’s wrong and we fix it.
Technology Choices – Our team lead likes that tool, so that’s what we use.
Changing Business Needs – They don’t really need it anymore, but we’ve already started.
Unrealistic Deadlines – The first release is due in two weeks, we started yesterday.
User Resistance – We don’t want it, we don’t need it and you can’t make us use it.
No Sponsorship – The spearhead for this left about a month ago…
Team Member Skill Level – We’re just finished training on X this morning.
No Best Practices – The Y team is different, we don’t use their methods.
J.S. Reel writes about Ten Signs of IS Project Failure via K.D. Maxwell and R.J. Custer. Robert Gordon writes about Projects that Succeed: 7 habits of IT Executives that know how to succeed. Gopal K. Kapur is quoted on his Management’s Seven Deadly Sins via CIO magazine. CardboardNU has checklists that help a project stay on track.
You plan projects for weeks, months, years but when its all over is a project postmortem a part of your process? A postmortem analyzes the project from start to finish and offers opinions as to what went right and what went wrong.
Computer gaming companies seem to conduct postmortem efforts more than other types of projects.
Eiji Aonuma, Director of the Legend of Zelda: The Wind Waker, says I’m always questioning myself after a project is over. GameDev.net has an article on how to conduct a postmortem by Steve Pavalino. Michael Greer has a list of review questions for a postmortem. Ed Yourdon recommends mini-postmortems.
My youngest son asked me an odd question, odd for a child, but even odder for a six year old child. He asked me if I would risk my life for him. I didn’t bat an eyelash with my response, and I’m sure there wasn’t anything terribly deep about his question. When I asked him why the question came up he said he saw it on a television show.
But it did get my mind churning. How many people did I know that I would risk my life for. Are there people I wouldn’t risk my life for? Under what conditions would I or wouldn’t I? My family members would be first on the list. I have a few close friends on the list as well. There are a few people I might let fall off a bridge, some I might even give a healthy push, stand at the top and cheer as they fell.
So, who would you risk your life for? Who would have a difficult time convincing you to pull them from the brink of death?
My great-great grand uncle, Stephen F. Fleharty, may have been the first blogger.
Although it was common practice for soldiers in the Civil War to write regular letters home or to the local newspaper editors, Fleharty did one better.
He actually authored his own column, “Jottings from Dixie”. Like today’s bloggers, perhaps he fashioned his writings after another prolific war time writer, John Adams.
He wrote for the general public, specifically friends and family of those in his company, the 102nd, in two different papers in Rock Island, Illinois. His columns, which he numbered and dated, were compiled and published as a book in 1999. I have done extensive genealogical research on my family lines but I did not find his book until I inherited his brother William’s (my great-grandfather) Civil war guard detail book. The detail book led me to a distant cousin who shared her mother’s material with me and the existence of the book.
His writings were, at times, lengthy essays and others were brief bits of timely information. He wrote about the wounded and the dead, the brave and the fearful. During a battle near Cassville, Georgia on May 21st, 1864, he describes his impressions:
I wish it were in my power to represent upon paper all the impressions received during the nine hours that we were under fire. But I cannot command words that will do justice to the subject. Yet in memory the scenes of that day are indelibly fixed. The cheers of the combatants; the roar of musketry; the groans of the wounded; the upturned faces of the ghastly dead can never be forgotten. And those who passed through the fiery ordeal will never forget the pecurliar zip, zip, zip of bullets as they barked the trees and clipped the leaves around them. (From Jottings from Dixie, Edited by Philip J. Reyburn and Terry L. Wilson.)
Megnut, a current day blogger offers a different perspective on the American Civil War.
So what the heck is a TrackBack and what is it used for? Read the MT manual’s definition page for TrackBack. Here’s SixApart’s specification for it. A couple of different definition pages here and here (Tom Coates).
Here’s a working example at Mitch Kapor’s site.
UserLand has a definition of how they will be using the feature here. They are testing it here. I’m pinging their entry with my entry.
Anyone feel couragous enough to ping mine? I’d like to see the Trackback in motion.
Have you found a great graphic that you’d like as your webpage background? Only one problem, once you put it on the page, it repeats across when you only wanted to see it once.
Here’s the fix. Insert this into the head section of your html page. That’s the part where the title is. It has a tag start of
or and ends with or . Insert the following right before the end tag. Change the /images/yourimage.jpg to the url for your background graphic.
This tells the background image to repeat down the page, not across. The style content inbetween the style tags tell the body to use the image and only repeat it vertically until the page has been rendered. It won’t repeat the graphic horizontally. Alternatively, the body style element can be added to a stylesheet instead of using it inline as I have here.
Anders Jacobsen talks about Dakota Indian Tribal Wisdom on Project Management. Here are a few others with added items for the list:
Management and Horse Racing
Horse Story – Common Advice from Horsetrainers
Perhaps businesses could take a few lessons from Seabiscuit’s trainer, Tom Smith, Tom was the ranch foreman at my family’s horseranch in Colorado before he left for California in the early 1910-1920s. My grandfather was a very quiet man and Tom was considered to be a near mute. I imagine that the conversations consisted mostly of yeps and nods. Seabiscuit opens tomorrow.
I’m definitely not wet behind the ears, suffering from being too green or a software or internet newbie. Instead, I’m more like in the valley over the hill when it comes to software development. I’ve been leading and participating in projects for more than 24 years. Yet, when I go on interviews its much more like having all my wisdom teeth pulled without anesthetic.
John Lockwood offers a comparison to how we might hire carpenters if we hired them like we do programmers here.
Its a great anti-analogy and exposes how terribly the process of hiring a programmer actually is for the programmer. Most hiring managers want specific and exact experience. Developers with more than one language skill may feel that learning another language is simple and they could pick it up easily, they don’t understand why they have to have the specific skill the hiring manager needs and wants.
Although its painful to be analyzed as much as programmers get analyzed in a job interview, we have to be aware that in many cases its because of others who have gone before us. Some programmers attempt to pass themselves of as more skilled and educated than they actually are. When they jump into the actual fire pit of the project and can’t do what they were hired for, the hiring manager gets a bad taste in their mouth, their hiring practice becomes that much tougher.
I consider myself a professional developer and feel capable that I could pull off learning just about any language or API. But does a hiring manager really want to pay me to learn or does he want me in front place straight out of the gate. I’ve also been a hiring manager, project and team lead responsible for doing the interviewing. Its not simple or fun to be on either end of the process.
So how do you make it easier? Identify the absolutes that you must have. Don’t be so specific that you eliminate the stars that truly could offer your project something even if they don’t have the specific skills you need. Look for people with skills that aren’t as easily taught. Look for the developer with communication skills, the team lead with development skills, the QA with software distribution knowledge. You don’t need a perfectly formed diamond, you need a diamond in the rough.
Communication or the lack of it can make or break a software development project. One of the simplest solutions to establishing a strong level of project communication is to establish a central repository for everything the project does. A blog can provide that repository, establishing a central location where team members can share both verbal and written communication.
Business blogging is establishing a project website for companies that either couldn’t afford the expense or the headache of installing more complex or expensive solutions. Blogging isn’t a silver bullet, but its a quick, inexpensive way of communicating among project members.
Publishing a project weblog via Inctura Daily. Phil Wolff refers to the process as Klogging. Articles by Phil Windley and Jonathan Peterson offer different perspectives on how projects can be managed with blogs. Another view is offered on Weblogs for PM.
I setout this morning to write a combination script that would allow people to subscribe to either my MT notification list or my Bloglet XML feed subscription. I was trying to see if I could allow them to do both. As I perked it over, I thought it would be nice to allow them to unsubscribe as well.
I sat down with my trusty notebook by my side to take notes and started to code. First version up and running on the page, now for testing it. Once, twice, three times it failed. Hmm.., what did I do wrong? Consult my PHP oracle, no its not the code, or is it? Distrusting my coding skills, like the perfect programmer that I am, I redid the code. After a few minutes of scratching my head, I did the unthinkable and tried someone else’s Bloglet subscription form. Theirs doesn’t work either. Ok, wasted some time with someone else’s problem. Rip out the Bloglet form and put back the regular MT subscription.
Now, I don’t like the way MT does notification. Notification, to me, should be transparent and automatic. MT only gets the transparent part right. Maybe I should jump into MT plugin land. Is the water ok guys?