Posts Tagged ‘project team’

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


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


An 8 Step Program for Recovering Micromanagers Like Me

Getting peak performance from a great project team is no mean feat. What can make the challenge particularly intense is a senior and seasoned team, combined with a complex project that requires large amounts of interaction and communication to coordinate effectively. For those PM’s highly skilled in the art of ruthless task management and no holds barred follow-up, it is not hard to let diligent and very necessary pursuit of closure outcomes slip into annoying and counterproductive micromanagement.

Why is this especially a concern with more senior teams? Because many senior people are often much better able to rise to the occasion of contributing to solving hard problems when the team environment both allows and encourages them to do so; and they are often the most likely to get bent out of shape and experience falling productivity when their manager starts to give detailed input on how to spend each minute of day.

I saw a recent blog post that was nicely on point to this issue, from the PM Alliance. I excerpt it below, but the slightly longer piece is worth the read as well here.

Credit: iStockPhoto.com

——————

8 Ways to Banish Your Inner Micromanager

By PM Alliance President, April 2, 2011

1 – Stop hovering. If you find yourself peering over a teammate’s shoulder, step back …

2 – Ask fewer questions. That’s right—instead of assuming that you need to request every bit of data you want, you should be relying on your team to keep you informed proactively [and holding them accountable for doing so]…

3 – Delegate more. Micromanagers are famous for giving tasks away without ever really letting go, and sometimes for not giving tasks away at all…

4 – Stick to working hours. Some projects require overtime, but constantly pulling employees’ brains back to work after they’ve gone home is just a variation of hovering…

5 – Empower your team. Are your employees forced to seek approval for every decision, from the big stuff all the way down to day-to-day minutiae? Set up a process that instills responsibility and grants authority based on each staff member’s seniority and experience.

6 – Watch your temper. Getting overly upset or losing your cool with employees is a classic sign of a micromanager. It frequently leads to hovering and incessant questioning, both of which you want to avoid. When you feel something isn’t going well, stop. Take a minute, gather your composure…

7 – Take mistakes in stride. Glitches are the siren song of the micromanager—they make it easy to doubt your team’s abilities, assume you have to do everything yourself, and generally make life miserable for those around you. Remember that mistakes happen to the best of us…

8 – Don’t let your boss bring you down. If your boss is a micromanager (or perhaps just a difficult personality), you may find yourself offloading stress by funneling your frustration and anger into your team. It’s a tough position to be in, but you somehow need to separate the way you’re being treated from how you treat your team…

 

As I said at the start, this is just an excerpt; the whole article is worth reading at: http://it.toolbox.com/blogs/project-management-tips/8-ways-to-banish-your-inner-micromanager-45275 BTW, the PMAlliance, Inc. is a project management consulting, project management training and project office development company that helps Fortune 1000 companies improve the execution of their mission-critical projects.

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


Successful Projects through Agile Project Management

Agile movement the “brain child” of the development world? 

by Nancy Nee.

Both traditional and agile project delivery embody similar principles and practices that aim to deliver measurable results. Traditional project delivery can be described as a “waterfall” approach, which presumes that the requirements, expectations, duration, activities and outcomes of projects can be predicted accurately and planned in a sequence before any actual development activity takes place.

In contrast with traditional project methods, agile methods emphasize the incremental delivery of working products or prototypes for client evaluation and optimization. While so-called “predictive” project management methods assume that the entire set of requirements and activities can be forecast at the beginning of the project, agile methods combine all the elements of product development, such as requirements, analysis, design, development and testing — in brief, regular iterations. Each iteration delivers a working product or prototype, and the response to that product or prototype serves as crucial input into the succeeding iterations.

Delivering “customer value” is a key aspect of agile project delivery. Agile project management is conducted through the collaboration of a small, co-located team that usually consists of the customer/end user, a project manager, a business analyst (or the role of business analysis) and specialist(s). Agile theory assumes that changes, improvements and additional features will be incorporated throughout the product development life cycle, and that change, rather than perceived as a failing of the process, is seen as an opportunity to improve the product and make it more fit for its use and business purpose.

Read the rest of this entry »

Tags: , , , ,


What Do Team Members Want From Their Project Manager?

ProjectManager

Project teams, want a project manager with the basic character traits, trust, integrity, respect and honestly. But a good project manager possess much more than these basic traits, a project team wants a manager that skilled at:

  • Information sharing.
  • If you don’t know—say so.
  • If you can’t say because you are under a promise of confidentiality—don’t lie.
  • Protection or “executive cover”.
  • Stretch your team with assignments.
  • Recognize a task or deliverable that is well done and give feedback.
  • Provide a clear understanding of what each team member is responsible for.
  • Try to solve problems identified by the team.
  • Be there when the going gets tough.
  • Defend the team from unreasoned and unreasonable demands.
  • Treat the team members like people who have lives outside the office.
  • To read more, click here.

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


    Project team member breaks leg – what next?

    broken_leg_kitten

    Just when you think you have planned for every possible outcome, the unexpected happens and a key part of the project team is out of action, possibly for months. Bringing a new team member in can be difficult for not on the team, but the new member, but there is some key steps to take to bring that person up to speed as quickly as possible. Not only should the project manager brief the new member, but also consider the other people that have a different view of the project, including the team and stakeholders.

    To read more, click here.

     

    - Michael Grollman

    Tags: , , ,