Archive for the ‘Uncategorized’ Category

Multitasking, good or bad?

We have all heard that some people are better at multitasking then others. My question is; does multitasking help a person complete project tasks successfully in the total time allowed for those tasks? Besides having multiple tasks to complete, there are also phone calls, IMs, emails, meetings and other interruptions that are relatively constant throughout a Project Manager’s typical day.

One habit that most of us face, throughout our lives, is losing focus. Once you are able to consistently focus on one task at a time it will then become easier to conquer this habit. Some things that can help you to stay focused are prioritize tasks, address one task at a time and keep the tasks small. Keeping a task small may involve breaking a large task down to several sequenced smaller tasks. If a critical task surfaces, address it and then go back to the task that you were working on prior to the critical task. If there is an interruption, try and schedule it for a later time, ignore it or keep it to a minimum.

I found the following link interesting on how to identify “bad multitasking” and ways to avoid it. Along with the tips is a podcast.

http://pm411.org/2009/09/29/podcast-episode-047-schedule-killers-bad-multitasking/

Podcast episode 047: schedule killers – bad multitasking September 29, 2009 By Ron Holohan, MBA PMP

Tags: , , , , ,


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: , , , , , , , , ,


To WBS or not to WBS?

 

Trying to strike a balance between agility and risk-mitigating structure is a difficult task for any PM.   This is true not just in software development, but in all projects.  Have you ever managed a project or been part of a project team where the stakes are high, but you feel that too much structure is in place?  Not only can this impede production, but it can frustrate the team and do more harm than good to the quality of the result.  The Agile methodology is so popular among development teams because of the low project management “friction” involved, giving the team the ability to chart and re-chart a course fairly quickly.

 

However, lest we begin to dismiss formal project management disciplines as relics of a by-gone era,  let’s remember that many studies show that between 60%-70% of IT projects are classified as failures by their stakeholders.  In the end, we can never forget who the project is for, and who defines success.

 

How do we know when to apply structure, and when it’s best to back out of the way?  As the following PM blog eloquently details, being selective about when to use a framework and when to back off is more art than science.  Enjoy!

 

http://projectmanagementblog.com/

 

Tom Streveler


Open & Agile

Like most I think I am a fan of all things open (it sounds better than closed) the term “OpenAgile” recently caught my eye.  The group pushing this term has a nice e-book pdf of their concept.

One of the people out in front on this is Mishkin Berteig. He seems to be combing some Scrum stuff, some Lean stuff, and something called the Learning Circle from the education world.  Other than having the e-book out there, I am not sure what is “open” about it, but the e-book is a quick read, and may prove useful to teams trying to find a form a Agile that works for them well.

- Michael Grollman

Tags: ,


Taking Scrum up a Notch with Smoother Agile

John Scumniotales , the co-creator of Scrum and the first Scrum Master (his words) did a really cool webinar on why agile environments needs more than Scrum.  Among other things, he lays out four key elements that are part of securing a successful agile environment, none of which are really top of the list in a pure scrum philosophy although not in any way antithetical to scrum, just a layer on top of it.):

  • Cross-functional teams that include the customer (or their proxy), development, test, documentation and anyone else required to create “the whole product”;
  • Incremental delivery of production quality capabilities at regular intervals;
  • Test-driven development that builds quality in from the beginning;
  • Automated and unattended build, test and reporting and I maniacal focus on build quality.

I particularly like the test driven development stuff.  You can check out the whole webinar here.

- Michael Grollman

Tags: ,


Getting performance measurements right in Agile environments

One of the hardest things to do in any agile development environment is the production of good metrics on productivity.  Jeff McKenna, one of the earliest leaders in agile development, put out a blog entry on just this point.  A key issue, Jeff points out, is that at all development varmints are based on team dynamics, and it is always difficult to separate out team productivity from individual productivity.

He suggests the following rule of thumb to help build evaluation and performance systems for ads all environments.

To summarize:
50% Team performance
25% Team evaluation
25% Individual growth in functional area

Read more here.

- Michael Grollman

Tags: ,


Of Axes and Saws

A.L.

A.L.

Successful projects have always required proper planning, at least that’s the old saw. I saw a neat post from Paul Ritchie, a PMP out of Rhode Island that helped to turn this old saw into a sharp new axe me for.

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” -- Abe Lincoln

Turns out this planning thing has been something on the todo list of successful people for a long time.  Check out the rest of Paul’s post here.

- Kari Marrs

Tags:


A PM’s long road trip to San Diego …

So when does a swamped project manager find time to write a blog… when trapped without internet on a long road trip to San Diego …

Road to San Diego

Road to San Diego

So many topics… so little time… what’s a gal to do?

I’m not really sure there’s a formal definition for the kind of project management we do.  As consulting project managers, my fellow project managers and I don’t really fall into what I would consider the standard PMI definition.  The catch phrase ‘on time, on budget’ still applies, but it’s a lot less academic and much more hands on.  We are not the types who are satisfied with high-level status updates for fancy project schedules.  We are in the trenches working with the client and the engineers to get the job done.  We are combination business analyst, user interface designer, technical writer, quality assurance specialist, business manager and fire fighter.

WE NEED TO KNOW EVERYTHING
Or at least it seems that way.  We need to know the business process, the user who will be using the system, the available technologies, the software best practices, and the technical possibilities.  I think it sometimes drives the people around us crazy, because we never stop asking questions and challenging assumptions in an effort to eliminate shades of gray and possible misunderstanding and re-work.  The possibilities are endless and there is never just one way to do something.  There isn’t even one best practice.   We have to synthesize the information from the business users and the software engineers, to make the most qualified recommendations.  And we are at our most effective when we have direct knowledge and understanding of the users who will be using the software systems.

BREAKING IT DOWN
One of the key criteria to success of any project is breaking down a large work effort into smaller bite size pieces in order to understand the dependencies (critical path), resources (people, software, time), and communication required.  My 5 year old’s favorite cartoon these days is Special Agent Oso… he’s oh sooo special.  He’s a panda bear in training to be a special agent, but his training missions are always interrupted by special missions to help kids learn how to do things.  Everything whether learning to hula hoop, play hide and seek, take the rabbit to school, or cook blueberry muffins, takes three steps to do it right.  In real life, it almost never takes just 3 steps, but the concept of breaking every task down into smaller steps helps tremendously.  Even to start writing my first blog entry… I couldn’t stop myself, I started breaking it down into possible topics.  And that part about getting interrupted for special assignments… it happens all the time.

Viva la blog… let’s see where this road trip takes us…

- Mara Pederson

August 2009

Tags: ,