Getting Things Done for Project Managers

Most, of the project managers that I know tend to be hyper organized, and always on top of things. It goes with the territory of course. They’re also more likley than most to have a set of processes for managing themselves and they might even be half decent at sticking to it.

But regardless of what you’re doing, if you’re a project manager and you’re not following David Allen’s “Getting Things Done” (GTD) framework for self organization and productivity, you’re probably not as effective as you could be. This post will walk you through the most important elements of GTD from a project managers perspective, and suggest some resources where you can fill in the gaps.

Why GTD?

The core of GTD is it’s agressive embrace of systems. I wouldn’t say it’s built for ease of use, in fact, it’s more like an unobtainable state of zen, for which its followers are eternally striving. There is reward in this striving however.

The aim of these systems is to get ALL of the things that you know or think you need to do out of your head and into a place you trust to retrieve it later. Nothing slips through the cracks.

A project manager’s raison-d’etre is to stop things from falling through the cracks! It’s not easy to obtain a perfect GTD practive, but if you do, you will find see the benefits in the quality and timeliness of the projects you manage.

So let’s get started.

Five lists

GTD is based on the use of five main lists, which can be broken into sub lists. These lists are:

1. In - The “In” list, is where you should write down any ideas or things you need to do as soon they occur to you. Just put it in this list as soon as you think of it, forget it and continue with your work. You might actually keep a couple of these lists in different places and formats, like your phone and agenda. That’s OK, as long as you are consistent about using them.

2. Next Actions - This list is the most like a traditional “to-do” list. The important thing here, is you need to phrase things as concrete action. So instead of something vague like “hire php developer”, list the next actual action like “post php developer job description on stackexchange”. You will be amazed at how putting a bit more thought into your action descriptions makes it so much easier to knock off items on your list.

3. Waiting For - This is where you put everything you need a response for. When you send of an email that you need a response for, it goes here. If you’re waiting on something before you can move forward, it goes here. 
   
   
4. Projects - GTD defines projects as anything with more than one action. Obviously this would include the projects you are overseeing a team on, but it would also include things like “Hiring a php developer” or “Buying a foosball table” 
   
   
5. Some day/maybe - Here is where you put those ideas that you can’t quite tackle yet. This is amazingly effective for getting those nagging “million dollar ideas” off your mind until you can really give them some thought.

For each action, you can include a “context”, which helps you to identify which of your next actions you can tackle in your current situation. Typical contexts would be “computer”, “Office”, “home”, “shopping”.

You might also include specific people as a context, or even energy levels. Some tasks require more focus or emotional investment, others not so much. You could use a “high-energy” or “low-energy” context for these items.

Calendar

The calendar should be restricted only to items that must happen at a specific time. Don’t use it for “reminders” like “check in on email integration feature development” unless you have a meeting scheduled for that time to discuss email integration.

Weekly Review

One of the items that you should put in your calendar, and treat as a concrete event, is a weekly GTD review. I like 10 am every Friday, but you might prefer a weekend. Whatever, go schedule it in now. I’ll wait for you.

These systems can really work for you, and improve your effectiveness as a project manager, but even the most obsessive compulsive people will begin to slip in some of their systems over time.

The weekly review is immensely helpful, and the time it requires is well worthwhile. Try it once, you’ll see how good it feels to have everything under control and actually know what you should be working on.

During the review you will:

• check off next actions that you’ve already done, or no longer need to do
• get down things you’ve been thinking about, but haven’t had the chance to capture yet
• Use a trigger list to help you reach the dark corner of your mind. I suggest starting with the massive one I’ve linked to here. As you go through it the first few times, cut out the parts that don’t apply to you, and add in new ones that are missing.
• Make sure each project has at least on “next action” associated with it
• Add relevant contexts to items that are missing them

The weekly review is the hardest part of GTD to stick to. But when you find you don’t have time for it, that’s when you need it most.

Tools

You should use the tools that work for you. A major variant (and point of debate) is how much paper to rely on. I prefer electronic tools, as they make editing, reordering and accessing them much easier.

• A very popular task list management tool for GTD is Nozbe
• A calendar is essential, any online calendar will suffice, though I like Google calendar. It’s beyond me how a paper calendar could work for anyone, but hey, whatever works for you.
• File folders - more details on how best to use them here

Resources

Intrigued? If this sounds like it can help you in your project management practice, there's tons more out there for you.

The book: Getting Things Done, by David Allen
GTD for CIOs, a great blog, useful beyond what the name implies
GTDTimes is the official blog run by David Allen's company, with tons of content for you.

Does GTD sound like something that can be helpful for you?

Top 5 Software Project Management Mistakes

Software projects are hard. Running out of time and budget is the norm, rather than the exception.

How can you prevent your project from ending in disaster?

Here are the top 5 mistakes you should avoid:

1. Following the Waterfall model

The Waterfall development model has long been considered fundamentally flawed for software development. It works for engineering projects in the physical world, but software development is very different from building a house.

Using the Waterfall model assumes that you know absolutely everything about the final system, before you even start.

Software is a living, ever-changing organism that grows and responds to changing needs and specifications.

A much better model is iterative development. This breaks the lifecycle of software down into many "mini-waterfall" phases that help you respond effectively to ongoing changes.

2. Insufficient upfront planning

In contrast, following an iterative process can sometimes lead to lack of sufficient upfront planning. It is tempting to start writing code on day one, before the problem is fully understood.

Instead, earlier iterative phases should focus on creating high-level documents explaining the "big picture" and major problems the software aims to solve. Depending on the complexity of the software, it doesn't need to be a full functional specification. It should simply have enough information to make sure everyone on the team understands what the software is supposed to do.

Next, it helps to rough out layout and interface details using mockups or wireframes.

Finally, before full implementation, it pays to build a "working prototype" that contains most of the user interface, but perhaps not all of the backend. This allows users to try things out and make suggestions when the cost of change is low.

3. Overly optimistic estimates

Programmers are notoriously optimistic when it comes to estimating how long programming tasks will take.

I blame this primarily on the "Programmer Optimism Curve" (POC) that I describe in the popular "You are not 90% done" article. This results from the actual scope being larger (often 4-8X) than originally expected.

I recommend being prudent and following these 5 steps to estimate software development time.

4. Adding too many people

Ever since the dawn of software development, managers have assumed that building software is just like building things in the physical world.

Nothing could be further from the truth.

In 1975, a brilliant computer scientist named Fred Brooks wrote a book called "The Mythical Man Month".

One of his many observations was that for a complex process like software development, you should keep your team as small as possible to reduce the total number of communication channels.

In fact, "Brook's Law" states that "adding manpower to a late software project makes it later," followed by the cheeky "Nine women can't make a baby in one month."

This holds true now just as much as it did when he wrote about it in the mid-70s.

5. Incorrect use of todo lists

Projects to-do lists often end up as a brain dump of specifications, questions to be answered, unapproved features, and miscellaneous chores that need to be done.

As I summarized in my personal blog, the best practices to make a to-do list work are:

• Using verbs
• Being specific
• Grouping by context
• Focusing on next

For a detailed account of why most todo lists don't work, and how to manage them better, be sure to read David Allen's "Getting Things Done" (GTD).

Summary and recommendations

In conclusion, to avoid making these common mistakes:

1. Use an Iterative development model, not Waterfall
2. Do enough upfront planning
3. Make realistic time estimates
4. Keep your team small
5. Use the GTD methodology for todo lists

Following these guidelines will give your project the best chance of success.

---

About the author: Jason Hanley has been developing commercial software since high school, and is the founder of PMRobot.com.

The Agile Boulder

I recently guest posted on Jim Ewel's great blog, agilemarketing.net, about creating roadmaps for agile marketing,
a technique I advocate for to help reconcile the potential for fragmented agile marketing campaigns.

Afterwards, Jim and I were discussing the difficulties of transitioning to Agile and Agile marketing. He made the good point, that there seem to be two different approaches to the organizational change necessary to implement agile practices. You can either go all in, or you can try to ease your way in.

Going all in means, taking the time to get full buy in from the executives and hiring a coach to guide the transition.

The other option is to easy your way in. Don't even use the words "agile" or "sprint" and certainly don't post up a manifesto! Rather, introduce one practice at a time and slowly reveal a better way of doing things.

My previous transitional effort was very much an attempt to ease the organization slowly into Agile. That experience led me to believe that it can't work. My conversation with Jim has me seeing it differently.

Organizational change is like moving a boulder

Introducing agile practices will only work if the processes aren't counter to the current culture. If the culture is in place, you're at the top of the hill. Simply apply a gentle amount of pressure; the boulder will gain speed on its own. Without the culture, you're in the wrong valley.  Outside help will be needed to help you get to the top of the hill and down the other side.

Where are you now?

If your culture already shares elements with the agile mindset, you can probably go with "easy does it". What does this culture look like?

- Shared accountability for delivering high quality products on time
- A collaborative approach between different disciplines
- A relatively flat structure
- Willingness to be wrong
- Adaptability

If most of these cultural elements are already in place, the processes will fit more easily.  Daily stand up meetings, visual task management and retrospectives won't go against the grain.  This allows you to make some small changes, demonstrate some easy wins and gain trust, before loudly declaring "WE'RE DOING AGILE NOW"!

If the culture you see around you doesn't so much look like that, you're not just looking at process changes, you're looking at cultural changes and culture comes from the top. In this case, you're better to focus on executing effectively under the status quo, building trust and slowly selling management on a better way of doing things. In this instance, you can benefit from the large volume of literature. The fact that "Agile" is becoming a buzz word can actually be your friend.

In this case, hiring an outside consultant is probably what's required to signal to the team the intention to change how people interact. Outside energy (the right outside energy) can also inject some enthusiasm around the possibility of a better way of doing things.

photo credit: cobalt123 via cc

- John Mardlin

5 ways to lose your job by "going agile"

 Yes, this is written from personal experience. With previous employer, I went to bat for the benefits of Agile project management. Though leaving was not a direct result of that effort, the relationship capital that I spent had a huge impact on my ability to add value. Eventually, I was clearly unhappy, they were clearly unhappy and we fairly amicably went our separate ways.

That said, the remainder of this post won't be written it in the first person. Doing so would  introduce too much of my own biases. Also, some of these points are slightly exaggerated from the actual occurrence so don't assume I'm as dumb as all that. 

I hope is that these hard-won lessons can be helpful to you in creating the change you want to see in your organization.  Regardless of  who you are or where you work, either as a project manager or team member;  in a large enterprise or a small consulting shop, in digital marketing or software development, I bet there's at least one pitfall I can help you avoid.

1. Complain about the current system

If you’re laboring under something like waterfall, or  a basic lack of project management processes, you can probably see that the grass is greener on the Agile side. If you're really antsy about it, you’ve probably read tons of great material at mountaingoatsoftware.com or maybe agilemarketing.net, and you know that things could be better.

Awesome, you are almost undeniably correct. But so what?

Bitching and moaning about the status quo is not a good way to create organizational change. Instead it’s a great way to create a rift within your team. Some of these people were involved in creating the current processes, conscious or not. Beating up on the these process doesn't make you look smarter than everyone else, it makes you look like you think you're smarter than everyone else.

Negativity begets pessimism. If you focus on what’s not working about your current project management processes, the natural tendency is to look for the downsides of any alternatives as well. Instead, paint a picture of the possibilities that you see for your team going agile.

2. Be stealthy

So, you’re using positivity to draw a compelling vision to get people on your side. Unless you’re an exceptional salesperson, you’re almost certain to get some push back. It can be frustrating. You might be tempted to just put up a taskboard in your office one day, in the hope that the value of making work visible will be immediately appreciated.

That can even work to some extent, it is really cool to actually see all the work in progress and in the backlog. But simply putting up a task board does not an agile team make. Assuming that everyone will follow your lead into agile is actually a very un-agile way of operating.

You’ve drunk the kool-aid and you know things can be better. Unfortunately, the truth is that things won’t get better if you don’t have proper buy in from the rest of your team. Take the time to have the conversations required to secure this buy-in, both above and below you. 

3. Get hung up on the software

When you’re at your most enthusiastic about the potential of transitioning to agile, it’s easy to get caught up in the fun of checking out all the different software tools out there. It is important, but it can be a distraction from the real issues.

A focus on software can easily devolve into a debate between the current “waterfall-y tool” and whichever shiny new “agile tool” you’ve got your eyes on. That’s not where you want the focus of your discussion. It should be about the processes used and cultural practices needed around those processes.

4. Drop balls

There’s nothing like an angry client or executive to put a damper on your efforts to create change. Never mind that things probably weren’t going all that smoothly in the first place; rational or not status quo bias makes it very likely that the blame will be laid at least partially on the transition to agile.

If you’re championing the transition, then you’re placing some of your own credibility on the line. Be aware of this, and be willing to put in the extra time and effort to protect your credibility by staying on top of information and deliverables.

5. Do it in a culture of fear

Take a look at your organization, and your own motivations for wanting to go agile. Maybe the agile manifesto speaks deeply to the kind of environment you’d like to work in. That may not be the case for the people around you. There’s a certain kind of safety in having a silo between you, and the developer two desks over.

Creating an agile culture requires that people step up and take responsibility for the quality of each deliverable (or story) at each stage of the process. Face it, your coworkers might not be cut out for agile.

If this describes your situation, it’s not worth the emotional energy required to fundamentally change the culture. Or more eloquently put:

Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks.

-Warren Buffett

Be open to the idea that Agile will never be a fit for your organization... then polish up your resume.

Doing it right

Having gone in depth about what not to do, here's a very quick list of how it should be done.

• Be humble
• Talk to people one on one about your vision, and what you see in it for them
• Get outside help
• Get training
• Be honest about the pros and cons
• Be patient, now might not be the time for your organization

Also, make sure to do your research, so you know what you're talking about. Here are some good starting points:

Agile Software

agilemanifesto.org
http://www.agilealliance.org/
mountaingoatsoftware.com

Agile Marketing

agilemarketingmanifesto.org

http://agilemarketing.net/

What do you think? Have you had similar experience or difficulty transitioning an organization to Agile practices? Any insights to share about how it should be done? Let us know in the comments.

-

- John Mardlin

The New Marketing: Agile, Lean and Loving

The debate is long over and Agile Development for software is here to stay.

But agile is getting to be much bigger than its beginnings in software. It’s spreading into many new areas of practice, and achieving prime buzzword status.

The advent of the internet and digital culture has had a huge impact on marketing. Perhaps more than any other sector outside of software, marketing has finally embraced Agile in a big way.

I wanted to learn more about how Agile is impacting marketing and digital agencies, so I sat down to talk with Jose Albis, founder of the Albis Consulting Group.

Q: Jose, how is Agile changing marketing?

Well, it’s not just Agile that’s changing marketing. I like to say that “In Today’s Marketing, growth is ALL: Agile, Lean and Loving”.

Being Agile is all about being responsive, creative and fast. Being Lean means working in iterative cycles, testing, measuring what works and what doesn’t and constantly improving based on data. Being Loving means humanizing brands authentically, building community, offering remarkable experiences and seeking meaningful engagement with customers. Noah Kagan calls it, Lovegasms.

These three ideas are changing marketing as we know it!

Q: Wow. Tell me about what Agile means for marketing.

Agile is a new way of doing marketing. It's a combination of traditional marketing, with the influence of the agile software development movement. It's driven by the nature of social media and digital culture, enabling brands to more effectively influence the universe by reacting to the rapidly changing conditions around them.

Being an agile marketer is like being Batman. Before Batman goes into a situation, he has goals and an overall plan, but he knows not everything will go according to his plan. So he has his utility belt with him, and at any time he can use whichever tool he needs from his belt. An agile digital marketer’s utility belt has tactics and strategies covering content marketing, A/B testing, landing pages, SEO, PPC, social media, contests, games, etc.

It's a shift away from planning out entire huge campaigns at the outset, and instead using the Scrum process. Planning a “sprint” of 3 or 4 weeks, it's more of an iterative process. After each sprint, we look back, see what worked, what didn't and then move forward. One of the frameworks that come to mind is the OODA loop.

Q: What's an OODA loop?

It's a concept that comes from the military: Observe, Orient, Decide, Act. Each sprint is a new OODA loop, we look back at the last sprint, see what worked, what that means, figure out how to use that, then execute. The speed and efficiency of the OODA loop can represent the competitive advantage of a small startup that is developing the same disrupting technology, against a bigger and slower giant corporation. Think of ‘first to market’.

Q: How closely does agile marketing resemble agile software?

It's very similar in its processes, for example The Scrum Process. I'm an industrial engineer, so it's very natural for me to look at a system and try to optimize it. Agile emerged from the world of software engineering which has special challenges, so it makes sense that engineers would create their own methodologies for managing their projects. Especially when the principles had been around for decades in the Toyota Production System.

Marketing has a lot of similarities to software, it's hard to plan the whole thing from start to finish, and it’s difficult to know how different parts are going to interact, until you build them and release them. Around 2005 or 2006, I personally experienced acceleration in SEO, PPC and Landing Pages which became more important, and marketing became more digital. Marketers were celebrating that direct response didn’t need 9 month cycles but only weeks or days, and at the same time Marketers became more dependent on designers, developers and IT in general.

The traditional paradigm is that marketers and engineers and developers can't communicate, like in the Dilbert cartoons.

But marketers had to learn to work with these IT departments, started to blend into Marketeering and they picked up Agile methods from them.

Q: How are clients reacting to Agile?

Most of my clients are finding it easier than ever before. Instead of me saying "First we're going to do 'this', then we're going to do 'this'... and we're not going to know anything until phase four, and it's going to cost you 10,000 bucks", they get amazing flexibility. Even my agreements are lean and agile, we fail fast to succeed faster. There's not a big commitment like with a big agency. It's very flexible and that way we learn about each other in the process. We work together for a few sprint sessions, and if the relationship is working well, we keep going.

Clients like it because we can get going right away, without having to spend tons of time planning up front and results are faster. A lot of the times we are working in projects that involve technology releases so the Scrum framework makes sense, like dancing to the same tune.

Q: What are some examples of brands doing agile really well?

Oreo is very agile with its use of social media. During the super bowl, the lights were down for maybe half an hour, and they managed to design and send out a very simple, clever, timely tweet within minutes, that was retweeted by thousands of people!

Power out? No problem. twitter.com/Oreo/status/29…

— Oreo Cookie (@Oreo) February 4, 2013

Their marketers are in a control room, reacting in real time and sending out materials designed for maximum impact.

Q: So why is it important for marketers to be loving?

What are humans, that brands are not, historically?

[John]: They’re physical beings? They have faces?

They are imperfect. Brands have always tried to look so good, so perfect, that they’re like a robot. That’s why, every time there is a challenge or an opportunity to apologize, it’s also an opportunity to display humanity, to be more loving.
Marketers should should think about how their brand would express itself if it were human. I, Jose, have my own human expressions, ways of speaking and thinking, and reacting to different situations. You have the human expressions that make you John.



So maybe your brand is "nice"... but everyone is “nice”, what is it really? Maybe your brand is assertive, like the Michelin man he’s like a super hero. Having that consistency is important and it's a huge opportunity for old brands to renew themselves.

Conclusion

Agile is changing the face of marketing, but it’s not alone. Being lean and loving brings the full package together and enables a brand to engage with the world in entirely new ways. These three forces are transforming the classic Mad Men advertiser into Marketing Ninjas,Gurus, and even Superheroes.

Thanks to Jose Albis for this fascinating discussion, follow him on twitter at @josealbis.

If you'd like to learn more about Agile, visit the Agile Development Manifesto and the Agile Marketing Manifesto.

- John Mardlin

How to take your Agency Agile: Interview with Greg Morrell, Co-Founder of AgencyAgile, Inc.

Transitioning any organization to Agile project management can be difficult. When you add in the complications digital agencies face (fixed priced, fixed scope, but still lots of changing needs from their clients, to name a few) it gets even more complicated. I spoke last week with Greg Morrell of AgencyAgile who spends his time deep inside interactive agencies helping them to make the cultural and methodological shifts necessary to succeed at Agile. He was kind enough to share a few insights and experiences with me.

How is Agile different in an agency environment?

Agile methods were developed in the software industry, with a basic relationship between the product owner and the team.  Agencies are much more complicated, they tend to have more stakeholders and the projects and goals are much more open ended than software or product development companies.

In software development environments, teams and their internal product owners plan work against a schedule and have some control (as well as flexibility) over what gets built and when. But agencies provide services for hire in a world of ever-changing needs and market forces, as well as the ongoing need to participate with consumers' as they interact with brands. The sands are always shifting, however schedule is usually locked in (a hard date for a product launch, as an example), as is budget, and in many ways scope.  It can seem impossible to use Agile when some of these core elements, scope, schedule and budget, are not flexible.

So when we help agencies with Agile, we focus on the things that we can impact with Agile – it actually still works very well.  We focus on things like reducing noise and eliminating needless waste.  Top on our list is maximizing the “flow” of the actual team – if they’re not delivering, then nothing is getting done.  And when we are able to address these things well, the project goes faster, and you’ll be better off than if you hadn’t used Agile.

Why should an agency go Agile?

Wow, Agile has so many benefits for agencies.  Culturally, an Agile agency is a more rewarding, engaging place to work, providing the talented teams agencies employ autonomy and more direct accountability for their collective output.  We find that agencies that can engage their clients in an Agile framework build deeper, more meaningful partnerships with their clients. And honestly, there are a lot of bottom-line benefits for the agency too: lower turn-over, less overhead, and higher project margins.

What's the most important thing for an agency to know if they're thinking of going Agile?

The most important thing to know is that it's about the culture changes more than it is about following a new process or using new tools. In our experience, it is about 70% versus 30%, culture and people versus processes and tools.  A lot of agencies we talk to say they are using Agile. Many do use pieces, but making Agile work well in an agency takes time and attention to supporting the principles of Agile. Sending PM’s to get SCRUM certification, doing daily check-ins, and using tools to manage and organize project information are not bad, but these don’t get you to change behaviors and build trusting teams that really excel. And given that some things just don’t work well at agencies without massive adjustment (such as Agile estimation techniques), we see these shops getting pretty mediocre results.  It doesn’t have to be that way, and these lukewarm results make Agile look bad…whereas it is really people not understanding how to make Agile work in an agency.

So we really need to work on the culture. That's why the first value of the Agile Manifesto is; "People and interactions over processes and tools". You need to get rid of silos in your organization and get people talking.

Another big difference is that projects that are doing Agile right typically have fewer activities that look like project management.  Most of the team members are the people doing the work, either on the business end or building something.  The organization ends up looking really flat.  Thats a big change from the hierarchical, top-down, job specialization approach agencies have grown into over the past decade.

Process is still important, but we don't get bogged down by trying to be overly prescriptive about it. You should take an iterative approach to improving it as you go.

What does this look like in practice?

Well, right now I'm working with an agency’s 12-person project with several key members offshore in Costa Rica.  It's absolutely crucial for an Agile project to have everybody on the same page.  Working with remote teams is harder, but it's still possible to get great results.  We meet daily either by teleconference or video chat. With a 3-hour time difference between locations, this means teams have to come in at some odd hours for the meeting. But we take turns, sometimes the team in Costa Rica comes in at odd hours, sometimes the team in California does.  Everyone needs to be on an equal footing, neither team is considered superior.
By the same token, we don't move on until we're sure that everyone is on the same page as far as the scope for the current iteration.  Some of our offshore team members aren't completely fluent in English, so if someone is quiet, we assume that they don't understand 100%.  An Agile team can only move as fast as its slowest member, so we end up spending a lot of time training the team in patience and communication. This can feel a bit painful at first, especially in a sprint planning session. However, once the entire team has common understanding of the work, we make up time pretty quickly over the duration of the sprint.

Conclusion

There you have it.  The challenges of implementing agile in an agency are significant and extend well beyond surface measures like scrum training, task boards and daily meetings. But done well, the pay off of agile is easily seen in happier employees and better results.

Greg makes it clear that the tools and processes are necessary, but the real key to agile is creating a culture of trust, creativity and innovation. Visit agencyagile.com and follow @agencyagile to learn more.

About Greg Morell, CSM

Greg is co-founder and partner at AgencyAgile, responsible for growing relationships with agencies while guiding agency and client teams through Agile transformation.

Greg has over 18 years of interactive agency experience, particularly in client services and program management, developing deep, long-term relationships with clients in a range of industries including Automotive (VW, Mazda, Toyota, Kia, Hyundai, and Nissan, CODA and Better Place), Technology (Microsoft, Adobe), Gaming and Entertainment (FX Networks, THQ, Gaikai, XBox), and Consumer Brands (Nike, Naked Juice).

As digital agency veteran, Greg has held executive leadership roles Proxicom, iCrossing, and BLITZ Agency. Greg has led teams and built collaborative partnerships across a wide spectrum of agency types (traditional, media, digital), founded upon clear vision, shared goals, transparency and accountability.

AgencyAgile was founded in 2011 by software and digital agency veterans Jack Skeels and Greg Morrell, with the mission to greatly improve how agencies execute work, and how agencies and clients work together.

Perils Of Multitasking infographic

As a follow-up to my productivity post entitled "Multitasking is toxic", Peter Kim emailed me a great infographic with some stats about how bad multitasking really is for you.

Have a look:

The original can be found here.

Take a vacation from project management!

Project management is great fun, but sometimes you need a break!

You might start packing up your laptop and smartphone to continue working the entire time.

Or...

Perhaps you'd like a real vacation?

In that case, you probably need to assign a point of contact to help your project run smoothly while you're away.

So how can PMRobot help with this?

We've built in a number of features to assign a "helper" to interface with your team members and clients while you're away.

All recent activity is listed in the Newsfeed, making it easy to see, at a glance, what needs attention.

The Member Overview feature lets you view another member's dashboard.

Meanwhile, you can use Redirect Clarification to redirect questions posed to people that are away.

Read the full details in our new tutorial entitled "Going on vacation."

How to: Manage Remote Projects

Managing a remote project is hard work!

Before starting Syllogistic Software, I worked for a large software corporation, and managed several remote teams. It was always a challenge to:

1. Stay on top of remote workers' task status
2. Communicate questions and answers
3. Help the remote workers keep up with everything else happening in the project

So what tools did I employ to help the situation?

1. Email
2. Conference calls
3. Microsoft Project

When I started my own software consulting company, I tried using these same tools, but found a few problems:

Problem 1: People don't answer email

Even back then, people were buried in email. They choose the easiest ones to answer and ignored the rest.

If you asked them a complicated question about the next steps of a project, it sat in their inbox for days, gradually pushed down the list by other incoming emails.

Problem 2: People forget what is said in meetings

To solve problem 1, I would often call or schedule a meeting. During the meeting, we would go over the questions, determine action items, and record them in meeting minutes.

Unfortunately, some of these actions items would sometimes still fall through the cracks, and not make it to a remote worker's todo list.

Problem 3: Microsoft Project only works for initial high-level planning

MS Project is a great tool for coming up with a "grand" plan before starting a project. But the pretty Gantt chart you create is only valid for a day or two before -- you guessed it -- something changes.

Then you have to go back and re-adjust everything, and your beautiful chart starts looking messy. A week later, there are 5 new scope items, and you're already well behind the planned schedule. Your project plan has essentially fallen to pieces, because you've been so busy putting out fires that you haven't had time to keep it current.

So how do we solve these problems?

After many years of iterating through various fixes, I came up with several techniques that worked:

Solution 1: Clarification questions

The very first version of PMRobot came with a feature called "Ask a clarification question." This remains one of the most important innovations.

When you ask someone a question, it tracks its status, and helps remind the person who has been asked the question. This way, they don't delay the entire project by forgetting to answer.

Solution 2: Track work items in one place

Instead of requiring people to keep track of everything they need to do on their own, create a central work repository that's easy to keep up-to-date.

PMRobot provides a dashboard for workers that shows them exactly what needs to be done, in the exact order they need to do it. After a quick glance, they know their next step.

In addition, if they ask a question about a particular feature, the answer isn't lost in some document called "Week 5 Meeting Minutes." The answer to their question is in the exact same place as all of the other work details.

Solution 3: Use a dynamic project management tool

Microsoft Project is great for static, high-level, upfront planning. If you need a rough overview of the "grand plan," it can help.

Once the project starts, however, you need a dynamic tool that makes it easy to add and update new information.

A major part of project management is change management. Clients change their minds, technology fails, people get sick, and generally -- things change.

Your project management tool needs to be built with change in mind.

PMRobot is built with change management at its core. Every feature helps you control the chaos, and manage each change one by one, getting you closer to meeting your project goals.

Summary

As you can see, many of the features built into PMRobot have been designed to solve very specific problems -- problems that are very common to software consulting.

If you're struggling to keep up with emails and conference calls, consider trying a new approach, and see how these techniques can help tame your chaotic project.

---

About the author: Jason Hanley loves bringing order to chaos. He travels around the world, manages a team of remote developers, and is constantly iterating and improving PMRobot.com.

- Jason Hanley

Top 3 Worst Ways to Manage a Team

Five years ago, I wrote a short post about the worst possible ways to manage people. These are still popular techniques that managers often fall back to.

So what are these common management traps you should avoid?

#3 - The Ostrich Mentality

People fighting? Project running eight weeks behind schedule? New technical challenges are making success look unfeasible?

No problem! Carry on, business as usual. No need for change. Let's just keep doing things the way we've always done them.

This is what I call the Ostrich Mentality. Just stick your head in the sand and hope everything turns out alright.

What do to instead?

Admit problems frankly, have a discussion, and take action to change things.

Not tomorrow, but today!

#2 - The Ditch Digging Theory

This is when a manager believes that every task in a complex business process is equivalent to simple manual labor.

When a project is running behind schedule, they simply add more people.

This concept works fine -- if you are indeed digging a ditch. If you're doing anything more complicated, it fails miserably.

Adding more people to a project that is already late can actually make it take longer! I discussed the details in my post about keeping your teams small.

What to do instead?

Realize that business and information technology projects are complex beasts, involving specialized knowledge, and lots of communication.

If a project is running late, resist the urge to add more people to speed it up.

Instead, focus on trimming the scope to the bare essentials, and getting a solid deliverable out there. Then, create a follow-up project for the remaining lower priority pieces.

#1 - The Warm Body Theory

This one bothers me personally the most, probably because it is so prevalent and so toxic.

When managers have "warm bodies" (ie. people sitting in an office or meeting room) in their field of view, they equate this to productivity.

Nothing could be further from the truth.

If your employees are physically present at the office 10-12 hours a day, how many of those hours do you think they are mentally present, and actively contributing to the project?

Pulling five people into a two-hour meeting to "discuss the schedule" might burn $1,000-$2,000 of budget, and accomplish next to nothing.

What to do instead?

Make the schedule (the real schedule) and task commitments public and accountable.

Track everything in a live, accurate system that the manager, workers, and clients can access and update in real time.

Embrace flexible working hours and telecommuting. Let people balance their work and life commitments.

Once you've clearly defined what needs to be done, and who is responsible for doing it, you won't need to chase people down every five minutes for a status update!

Summary

To briefly summarize, here are the top 3 management "techniques" to avoid, and how:

• The Ostrich Mentality: Keep your head above the sand and take action!
• The Ditch Digging Theory: Don't add more people to a late project!
• The Warm Body Theory: Track accountability, and let people take responsibility!

---

About the author: Jason M. Hanley has owned a software consulting company for 9 years, and is the founder of PMRobot.

New Feature: Two-step verification

The standard ticket workflow in PMRobot is very simple. For instance, if someone finds a problem:

1. A bug ticket is submitted and assigned
2. The bug is fixed and marked 'resolved'
3. The ticket is returned to the original submitter to be verified

There are cases, however, when you need an extra level of verification.

For instance, if it's a very complicated problem that requires a lot of testing, you may want a member of your Quality Assurance team to check the resolution first.

As of this week's release, PMRobot now supports this workflow in two ways:

1. A project can have a "default verifier" who will be required to verify tickets first, before they are returned to the original submitter
2. Individual tickets can set the "verifier" field to require two-step verification for just that ticket

The new workflow looks like this:

This new workflow is very powerful, but completely optional. If you don't set a verifier, everything will work exactly as it always has.

If you'd like to learn more, check out the full tutorial at:
  http://help.pmrobot.com/2012/tutorials/two-step-verification/

And if you have questions, don't hesitate to contact us here.

The history of issue tracking systems

Web-based issue tracking systems (often referred to as "bug tracking" systems) have been around for a long time. Let's take a trip down memory lane and review issue tracking software to date.

1998 - Bugzilla

Bugzilla is arguably the great-grandfather of all web-based bug tracking systems. Written in Perl in 1998, and still in active use today, it defined a lot of conventions used by the systems that followed.

A bug in the basic Bugzilla workflow can be in one of the following states:

1. Unconfirmed
2. New
3. Assigned
4. Resolved
5. Reopened
6. Verified
7. Closed

Bugs can transition between these states in a number of standard ways. For example, when a developer completes work on a bug, it moves from Assigned to Resolved. A quality assurance (QA) person then tests and can put the bug into the Verified state if the developer's fix is confirmed.

This workflow has remained largely unchanged over the years.

In addition to bugs, Bugzilla allows "tickets" to track and prioritize feature requests in the same database.

2000 - Mantis Bug Tracker

Started in 2000, but not reaching version 1.0 until 2006, Mantis Bug Tracker (or "MantisBT") is a popular open source bug tracker written in PHP.

It introduced a much nicer user interface than Bugzilla, and offered more customization, including customization of the bug workflow and state transitions.

Although primarily meant for open source projects, Mantis is a very capable system. We used it for several years at Syllogistic Software prior to development of PMRobot.

2003 - JIRA

JIRA, a commercial product launched in 2003 and built in Java, represented another step forward for issue tracking systems, adding additional customization options, and a powerful plugin architecture.

In addition to issue tracking, Atlassian offers a number of products that integrate with JIRA to help with project management, documentation, and source control integration.

The JIRA platform tends to work best for large enterprise software projects.

2006 - Trac and Redmine

In 2006, two similar projects were born: Trac and Redmine. Both are open-source project management and issue tracking systems. Both offer web-based ticketing system similar to Mantis, along with support for milestones, Wiki-style documentation, and source integration.

Trac is written in Python (a language favored by Google), whereas Redmine was developed on the recently popular Ruby on Rails framework.

Both systems have a multitude of functionality, but their user interfaces can be confusing for beginners or non-technical users. They are targeted towards open source projects, or other highly technical teams.

2008 - Pivotal Tracker

Although it focuses more on agile feature tracking than issue tracking, Pivotal Tracker introduced a number of innovative user interface enhancements.

Its extensive use of multi-column drag and drop allows quick reordering of "stories" (similar to tickets). The UI also allows for one-click transitions between states with buttons such as "Finish", "Accept" and "Reject" easily accessible on the main story list.

Using Pivotal requires a through understanding of the Agile Methodology, and is best suited for organizations that have fully adopted it. The software uses many Agile terms in the interface, and assumes that your process mirrors the built-in states.

It is best suited for organizations that have a stable, fixed team working on long-term projects. Otherwise the "story point" estimation methodology, and overall workflow, tends not to work well.

2012 - What's next?

It's been nearly four years since the last major innovation in issue tracking.

We're seeing a lot of action in the mobile world, but mostly iOS and Android applications to access existing issue tracking systems.

What's the next big thing in issue tracking? Let us know in the comments below.

You are not 90% done

Have you ever had a programmer tell you that they're 90% done?

It happens all the time. Don't believe them.

I'm a programmer. I should know.

You see, there's a funny thing with software. It's very fluid, and can end up being very complicated.

For simple tasks, it's fairly easy to estimate the effort required, based on previous experience.

An example often used in project management literature is "digging a ditch".

If an average man can dig a 10 meter long ditch in 1 hour, then some excellently simple math can tell you that:

• That same man can dig a 20 meter ditch in 2 hours
• 30 men can dig a 300 meter ditch in 1 hour
• 500 men can dig 50 100 meter ditches in 1 hour

Unfortunately there are a lot of people that still try to apply this same logic to software development.

It simply doesn't work. Here's why. Let me tell you a little story.

Mark the Manager gives Peter the Programmer a specification for a new, complex feature in an existing, complicated piece of software.

Mark asks for an estimate, to which Peter replies, "Well, there are a lot of unknowns, but based on the spec, I think 2-3 weeks. Worst case scenario? 4 weeks."

Mark would like it done faster, but agrees to the estimated timeline and gives the green light.

Peter starts working steadily, 40 hours a week, with no vacation, personal, or sick time.

Here are his progress reports:

• Week 1: 35% complete -- Perfectly on schedule
• Week 2: 65% complete -- A bit behind, but still on track
• Week 3: 85% complete -- Uh oh, but at least we'll have it next week
• Week 4: 90% complete -- Ok, now we're late
• Week 5: 95% complete -- Customers are getting anxious
• Week 6: 97% complete -- Customers are irate
• Week 7: 99% complete -- Customers are leaving
• Week 8: 100% complete -- We are bankrupt

Disaster! What went so terribly wrong?

Perhaps the following visualization will help:

This is such a common curve in software development, it should have a name. If it doesn't already, I propose calling it the "Programmer Optimism Curve" or POC.

So what do we do to prevent this from happening? There is clearly no silver bullet solution.

I've written about my 5-step software development estimation method. That can certainly help.

The "story point" methodology from Agile can also work well when you have a long project with the same team members.

Jeff Atwood has some good suggestions about listing todo items too.

Of course, "knowing is half the battle," so now that you're aware of the problem, you can start taking active steps to keep it from sinking your ship.

- Jason Hanley

Eating your own dog food

There's an odd term in the software industry called "eating your own dog food."

Microsoft coined this term in the late 80s.

The main idea is that companies that make a product should use that product on a daily basis. That way, you can experience the pleasure (or pain) yourself, and have a better idea of where to focus resources.

At PMRobot, we use our own software every day.

It was conceived and born in our sister company, Syllogistic Software, and continues a core element of our processes.

"Dogfooding," as its often referred to, is absolutely essential when building a product, because it really helps motivate internal innovation, and quick fixes to problems.

A similar example, dating all the way back to 1981, is when Apple decreed in a memo:

“EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc. Apple is an innovative company. We must believe and lead in all areas. If word processing is so neat, then let's all use it! Goal: by 1-1-81, NO typewriters at Apple... We believe the typewriter is obsolete. Let's prove it inside before we try and convince our customers.” - An Apple On Every Desk

If an annoying change makes it to the server, we experience the pain first hand, instead of just hearing a second hand account from our customers.

If you develop a product, consider making daily use of that product a habit.

I guarantee it will help you produce something of much higher quality.

5 steps to estimate software development time

Here's an oldie but a goodie from my personal blog summarized for you here:

Estimating software development time is really, really hard. Here's my method:

1. Come up with your best, realistic estimate using your favorite technique.
2. Ok, you have your absolutely realistic number now, right?
3. It's not realistic. There are aspects you haven't thought of. Double the number. This is your best case scenario estimate, if there are no snags or major changes along the way.
4. Now double it again. This is your most likely estimate. This is how long the project will probably take.
5. Now double it a final time. This is your worst case scenario. This is how long is might take if you run into several major issues.

So to sum up:

• E = Your original time estimate
• 2(E) = Best case scenario time in reality
• 4(E) = Most likely time in reality
• 8(E) = Worst case scenario time in reality

- Jason Hanley

Multitasking is toxic

Everybody multitasks. But should we?

People consistently overestimate their multitasking ability.

There is huge power and efficiency to be gained by batching similar tasks, or "single-tasking" as I like to call it.

Email, social networking, and especially chat programs are notorious for breaking focus and concentration.

I discovered what a difference this makes when I was running my company from New Zealand and all my clients and employees were in North America.

There was a more than a 12-hour time difference, so I was essentially forced to track and batch all my tasks using an early version of PMRobot.

When I got up in the morning, the day had already ended in North America, and I was able to get work done with zero interruptions.

This resulted in a huge productivity boost!

As I'm writing this blog post, I have a number of tabs open for related material, but I've closed Gmail, Twitter, Facebook, and anything that could interrupt my flow.

I do the same thing when I'm programming. Before I open Eclipse to write code, I close everything else that's not related.

What time is it where you are right now? What major goals have you accomplished today? How many interruptions have you had?

Trust me, give single-tasking a try! I guarantee you'll be more productive.

Keep it simple: Ticket workflow

A lot of tracking systems have very complex ticket workflows.

These are often designed to prevent mistakes, but I've found that they often add too many steps to the process, which people eventually ignore.

With PMRobot, we decided to go a different direction, and limit ticket states to:

1. Open - There is work remaining
2. Resolved - The person who did the work believes it is completed
3. Closed - The person who submitted the ticket confirms it is completed
4. Blocked - Work cannot continue due to an external factor (used sparingly)

There are a few common states we decided to leave out since we didn't feel they added sufficient value. Here's why:

New: This is an an open, unassigned ticket. Why add an extra step?

Accepted: This isn't much different than an open, assigned ticket. Again, we don't see a lot of value in adding this extra step.

In progress: This is a useful state to have, but often isn't used correctly. People often mark ticket in progress and then forget about them. Instead, we tend to use time logs and auto-scrum to track what is currently being worked on.

Reopened: This doesn't seem to add much value over the 'open' state. We track and display the number of times a ticket has been reopened, but don't feel it requires a separate state.

What about your process? Do you use states I haven't listed here? Tell us about your experience with ticket workflow.