Posts Tagged ‘project planning’

Little bits of time add up to one powerful animal for demonstrating PM skills







The elephant should respect the mouse

 

Time is one of the three key axes of classic project control, along with financial resources and conformance to requirements.   Project managers appropriately put major emphasis on time as displayed on the wall calendar, and great energy is spent on hitting deadlines measured in days, weeks, and months.  When a project comes in on or before a due date, the PM can be justly proud (assuming no major feathers have been ruffled in the budget and quality domains).

Time on the calendar, master schedule, is a something of the elephant in the room when we talk about time in the project context.  But I want to talk a little about the mouse, time as measured in minutes, and how a project manager can put that mouse to work in service of the greater good.  One mouse in particular is an easy one to tame, with a reward – making sure that scheduled meetings end on or before their planned and published end point.

What’s the big deal with a meeting running late?  Happens every day, right?

The big deal is team cohesion.  One of the major duties of the PM is to ensure good communication, and meetings are a vital technique for getting messages to move well between people on a project team.  This gives the PM the powerbase for calling meetings and helping to guide them to productive results.  But when the PM’s meetings run long (and especially when a reputation develops that the PM’s meetings often run over) a few things happen.

First, the team begins to suspect that the PM has not done an effective job of planning the meeting agenda.  This erodes confidence in the project leadership.  Second, the team begins to sense that the PM may not respect the team members time, because a late meeting will usually result in a cascade of lateness after this meeting for them, which can create subtle or perhaps even not so subtle resentment.  Third, and this is particularly the case of the PM does much of the speaking at his or her meetings, the team may begin to feel like the PM is using power in uncool ways — or perhaps if there are other chatterboxes running off at the mouth, and the PM can’t control it, the PM may be accused of being to weak to use power as it should be used.

So, the PM who builds a reputation for always having meetings that run over gets thought of as not worthy of the team’s confidence, as a target of resentment, or as a serial weakling or a serial abuser of authority.  How much harder is it to lead a team to great overall results when the PM is forced to carry this kind of baggage.

Now imagine for the moment the reciprocal – the PM who’s meetings either end spot on schedule, with the work of meeting done, or even more delightful, the meeting that plows through its agenda and winds up done 10 minutes early.  Do this for a few projects, and then see how easy it can be to attract a talent to your team for future projects.  Excited talent.

Now a perfect set of meetings is not going to make up for project that can’t hit a date on the calendar or manage its budget. But getting the little things right is how we build to the big ones.  Take a look at the Mythbusters clip above, which shows that real world elephants show real respect for the real world mouse.  You ask me, this is no accident of nature – respect the mouse – good things will follow.

Tags: , , , , , , , , ,


Some landmines for new PMO’s to carefully step around

 

The folks at Daptiv through the gantthead.com site (http://www.gantthead.com/default.cfm) put out a nice white paper on how to NOT implement a new PMO. The title is Top 10 PMO Worst Practices: Pitfalls to Avoid. You have to register to get it (http://www.gantthead.com/survey/survey.cfm?ID=515) but it’s a fairly painless form, I would recommend this to anyone who is looking for best (and worst) practices at a PMO in 2011.

Here are 3 of the top 10, in no special order, three that jumped out at me, although the whole paper is worth a read to be sure, and this is not to say the other 7 are any less important. The comments for these are my own.

The PMO playing methodology cop.

Goes without saying that the PMO needs cooperation across groups. While getting standards for frameworks and methodologies and following them is valuable, getting cooperation from other divisions and departments is priceless. Whenever possible, adoption of common standards for methodology and framework should be through a common movement towards best practices. Education is the key to making this work well, not rigid top down dictates that may not even be the right solution for a given’s department PM issue set anyway.

Not matching demand to supply.

The PMO is uniquely positioned to assist in resource loading balancing across organizational boundaries. But the PMO needs to try and keep track of its own limitations – just because you have a project which business owners demand, does not mean your current team can effectively deal with them. Which leads to the third one, keeping track of your time.

Not logging time.

Service organizations in general, and busy PMO’s in particular, need metrics to manage capacity, and in people-based businesses, metrics are invariably tied to time management. If you don’t measure time, you cannot do effective capacity planning. Most PM’s do not love using detailed time tracking systems. But this is one of those “you must bite the bullet and just do it” issues. Without this data, it is very difficult to make good decisions about capacity.

Tags: , , , , ,


Project Teams in Space: The Times Are Changin’ (Again)

What makes for a productive software development office environment?   How much “close” company is too much, and how much isolation and quiet is simply too much?  When is an interruption welcome and needed, and when is it a mental reboot that sets back focus by 15-30 minutes each and every time it hits?  When is management’s new ‘space plan’ about creating great teamwork, and when is it about seeing how many people can be crammed into the smallest number of square feet of costly grade A office space?

As near as I can tell, there are no absolute answers to these questions, just a a series of tradeoffs that each manager needs to evaluate in putting together a plan for how the work environment for their team best goes together.  But while there may not be final answers, there sure are fads and trends. Let me give you a hint – the trend is not heading towards more square footage per person in most places, although there is still a movement afoot to keep the noise to a dull roar in some of the more technically intense shops.  Cara Garretson of ComputerWord put together a nice piece that talks about where these trends are heading just now.  The piece is worth a look.

 

 

Cubicle wars: Best and worst office setups for tech workers

Open office layouts are all the rage these days. But is that how IT folks work best?

By Cara Garretson

ComputerWord 2011

Computerworld – Consider the modern office layout: Open floor plan, lots of common space flooded with natural light, clusters of “pods” with low partitions (or none), all designed to encourage teamwork, boost productivity and — management hopes — improve the bottom line.

That type of office layout looks great on the company’s Web site, and most likely the creative team loves it, but does IT? After all, many high-tech employees prefer to work in solitude, or at least in an environment quiet enough to foster intense concentration for significant chunks of time. Are these trendy open office layouts torture to the techie brain?

To be sure, Web 2.0 has birthed new types of technology employees who depend on — even thrive by — working in groups. Web designers and developers, project managers, system architects, even some software developers are embracing office layouts that encourage interaction. Practitioners of the Agile Software Development movement have even come up with templates for office furniture arrangements that are physical embodiments of the Agile principles of openness and collaboration (see example, below).

On the other hand, asking programmers or network administrators to do their jobs in an open space where noise, distractions and interruptions abound can be akin, for some of them at least, to departmental decimation.

 

Read all from Garretson’s  article here.

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


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