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

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

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.

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.

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.

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.

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.

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 more)

On a recent training course the idea of change was discussed and the best solutions for this element of project management were suggested to be:

1. Communicate throughout the change.

2. Wherever possible involve people in the change.

3. Recognise the new skills and behaviours that people need to adopt.

4. Develop a clear vision about what the company wants to achieve.

5. Clearly identify risks.

6. Test motivation levels

7. Recognise that no matter how hard you try, there will still be some people who will not ‘come on board’

8. Face up to the fact that you may well have to have those difficult conversations.

9. Ensure you have a plan.

10. Clear leadership is needed in any change.

But one critical aspect that experts agree on is Speed. The lack of speed caused them extra problems.

To read more, click here.

However… it’s not fool proof and it only helps up to a certain point.

Momma knows best

It doesn’t prevent people who consider themselves usability experts from making mistakes.  I had a recent experience with a client who said they wanted best practice user interface design, but then demanded everything be done exactly the way they specified.  I created screen mockups exactly as the client requested to avoid the “brass knuckles”, but then provided tweaked versions to try and make it more user-friendly.  It not only added overhead to the process and eliminated creative collaboration, but made every effort at trying to guide the design process a bruising experience.  Frankly, it doesn’t matter how pixel perfect the screen mockup is and if it represents exactly what the client asked for, if the real users are left out of the evaluation, the code will need to be re-written if they refuse to use it.

Setting expectations / Better feedback

The other complication to screen mockups is that they can lead to the impression that the software will look *exactly* like the screen mockup.  I should mention that my screen mockups look like someone took a full 24 bit color picture of a real application.  When laced together in PowerPoint I’ve had people believe it is real software.  Up until now I have always preferred doing mockups with a paint program, because I love color, it helps me visualize what the application will look like, it is very efficient, and there are no artificial limitations on placement, color or functionality that might be imposed by a screen mockup program.  It also does not have the limitations imposed by prototyping tools which constrain how the user interface can function, and could lead to licensing and ongoing maintenance costs if integrated with the development code.

However… I am starting to think it can be a mistake in the wrong context, and I am reconsidering that in some cases black and white wireframes might be better.  There is a great blog entry from Creating Passionate Users which talks about making the demo match how done the application is to foster better feedback from non-developers.  She postulates that “the more “done” something appears, the more narrow and incremental the feedback.  This correlates with some of the unexpected feedback we received on a recent project, where the client spent a considerable amount of time debating what the icons should look like and the color of the fonts, while we were more concerned about whether the functionality was right or not.  The additional complication was that the client became addicted to wanting everything in a screen mockup, even when development was well under way.

http://headrush.typepad.com/creating_passionate_users/2006/12/dont_make_the_d.html

So apparently I am late to the party… I guess I’m not the only one who has run into this issue before.  After poking around and looking at a variety of screen mockup applications I’ve found more than a few where a key selling point is that the output can be made to look like it was essentially drawn on a napkin.  Sigh… Sounds like I’ll have to get rid of my nice satin table linens and pull out the paper napkins.  

Mara Pederson, May 2010