Posts Tagged ‘project phases’

The Bumpy Washboard Anti-Pattern

I came across this great blog from Leading Answers, which made me think of a bumpy adventure I had while driving through our wonderful state of Arizona on a return trip from Las Vegas.  I came upon a fatality accident, which we all know will keep the road closed for hours.  I had the choice of driving all the way back to the Interstate (a known route that would add 6 hours to the trip), or taking a detour down an unknown route.  Yes, you guessed it, I took the unknown detour thinking it would save time!  The detour started out fine until it turned into a dirt road and darkness fell.  6 hours later on what turned out to be a very bumpy dirt road, I made it back on the interstate.  If I had gone the original route with the smoother surface, it would have taken the same amount of time, but there would have been less wear and tear on my car, my stress level, and my hindquarters.  If you can remove the bumps in a project so there aren’t gaps in knowledge, then while it may still take the same length of time, there will be less wear and tear on the whole project team as everyone is able to collaborate to achieve the objectives.

Wash-boarding is an instability that occurs when vehicles move on dirt roads. What starts off with a small bump turns into a whole series of small bumps as vehicles travel the road. Washboard roads are more dangerous than smooth dirt roads and have to be driven at lower speeds. All these bumps are a pain in the rear (literally) and make you go slower.

We see the resourcing equivalent of washboard roads in projects too. Traditional projects staff early with business analysts to do the bulk of the requirements gathering and then bring in developers and finally QA people. These peaks and valleys of specialization not only look like a washboard road, but they have the same effect, they are a pain in the rear and make you go slower.

You can read the piece here:  http://leadinganswers.typepad.com/leading_answers/2011/06/the-washboard-anti-pattern.html

Tags: , , , , ,

This entry was posted on Tuesday, July 12th, 2011 at 5:00 pm and is filed under Leadership, Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Check this box if you think you are exempt…

Building software is hard! There are minefields everywhere…and if you don’t get the basics right the project is going to explode. Everyone hide in the bunkers right now, because when I say ‘the basics’, the basic that is the topic of the day is TESTING. Just because the letters QA are nowhere to be seen in your job description you are not exempt from the responsibility/accountability.

Now that I have your attention, I promise no more military references. But I also promise that reading on will force a gut check of your testing awareness. Today is a re-blog and it’s an oldie but goodie. One of those that makes you laugh lightly when you read it, but deep down in your core you know most of it rings true and hints at your organization’s flaws. Its title: The Joel Test: 12 Steps to Better Code implies that that the target audience is developers…but those of us who are always on the lookout for motive know that the post was likely intended to be used as ammunition (sorry… incentive)for PMs to get budget to upgrade their defect tracking software or hire another testing resource.

More thoughts on this blog:

• Giggling at the Netscape references may date you.

• The writing style is entertaining enough that your peers will read it all the way through and so will your developers, after which they will initiate much conversation about how you can help them do their job better. Be sure to tell them that improvement takes time, and unless you are a hard-core Commercial house, a score of 8 or above on ‘The Joel Test’ is perfectly respectable for the moment.

• Each question is open to interpretation; everyone’s definition of quiet or up-to-date is different. Bottom line: if your score is lower than 6, then you now know what needs to be done!

http://www.joelonsoftware.com/articles/fog0000000043.html

 

Post your score and any related *issues* here so everyone can discuss how to improve the testing model within your organization.

Tags: , , , , , , , , ,

This entry was posted on Monday, November 15th, 2010 at 8:49 am and is filed under Agile Development, Business Drivers, Project Management, Technology, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Project Scope – Customer needs to be shown the right path

upside-down-house-poland

Setting up a project plan and locking team members into their roles sets a good basis for project success. But once the details have been ironed out and the project is nearing completion the customer may come back with major additions turning the project upside down. Instead of pulling the project team off task, go back to the client and explain the situation. Work out ways of breaking the project into phases, this will give the client physical results that they can then build on.

To read more, click here.

Tags: , , , , ,

This entry was posted on Thursday, November 5th, 2009 at 8:15 am and is filed under Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.