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

How to Do Remote Work the Right Way: 13 Dos and Don'ts

In your day so far, how many people have you interacted with who weren’t in the same room as you?  The ease of communication has increased the amount of remote workers and distributed teams. This trend will continue, despite recent moves made by BestBuy and Yahoo to curb remote work.

This is the situation for the team behind PMRobot and part of the inspiration for our online project management app. Our team members work from their homes or in co-working spaces across 3 time zones in Canada. These are some of the things that we’ve learned about making it work.

The Dos:

1. DO use collaborative tools that promote simplicity of interaction

Google Drive (formerly Docs) is our favorite tool for creating and sharing documents. The ability to collaboratively edit and comment, as well as store any kind of file, in seemingly unlimited amounts are hugely useful.

Skype is ideal when higher bandwidth communications are needed. If you need a longer phone call, you might as well go for a Skype conversation - using video adds an extra layer of context.

Google Hangouts is emerging as another very useful tool, which is easy to get into if you’re already using Google Apps, and doesn't require a desktop client. In the past, I’ve have had some trouble with the connection, so if you’re attending an important meeting with a client or other external contact, I'd recommend using Skype.

For wireframing, we use Moqups, which at this point is completely free and very user-friendly, but doesn't yet support collaboration. For collaborative wireframing, Balsamiq is a great option.

A tool for managing your projects is also helpful, much better than a random assortment of spreadsheets and to-do lists. If you’re a digital agency or software consulting firm, PMRobot has been powering remote teams for three years now.

2. DO meet in person at the beginning of the project

In truth, communicating complex ideas and building relationships is more difficult over distances. Meeting in person beforehand is important for developing trust and alignment of goals.

You have a lot to accomplish during a project kickoff meeting: Trust is established, goals and expectations are hammered out. Even if you’re not following a waterfall model, a common understanding and preliminary specifications need to be determined at the beginning.

3. DO ask for estimated deadlines, and follow-up if they aren't met

When you’re not co-located, you can’t simply turn to the desk beside you and ask about a piece of work. Similar to a kickoff meeting, individual tasks or stories require more communication before work begins. Asking the person doing the work to choose his or her deadline not only sets expectations, but empowers him or her to set their own bar and succeed on his or her own terms.

If the problem turns out to be more work than expected, it might not be worth doing. Getting an estimated deadline from the person doing the work ensures they’re working toward a finite goal. Following up after the deadline reinforces accountability, provides a check-in, just in case things aren’t going as planned.

4. DO use a chat tool 

Email communication has its strengths, but it’s also time consuming and has a slow feedback loop. A simple chat tool removes a lot of the friction to initiating a discussion and has the advantage over email of a faster response time.

Anything works, Hipchat, Google talk, AIM, Skype or even mIRC. Just make sure you play by the common chat rules of conduct. Respect your colleagues’ “busy” status so they can dive deeply into a problem without interruption, but also ensure you make yourself “available” when you’re checking and sending emails or other less involved tasks.

5. DO set up a phone call if the email conversation is getting emotional

An over reliance on email drags things out and causes tension and writing an email probably takes longer than you think. A few 20-minute emails add up to a few hours pretty quickly - eating up your time and the recipient's! Emotional emails can take even longer to write, and then more time still spent picking up after the fallout later on.

As soon as you realize that you’re about to send an emotionally charged email, get into your chat tool and set up a call instead.

6. DO Answer questions within a MAXIMUM of 24 hours

Unanswered questions lead to stalled tasks. Stalled tasks lead workers to start new tasks. Further stalled tasks compound, creating a pileup of unfinished business. Having too much work in progress is distracting and demoralizing. Be prompt in your responses to keep open loops from accumulating.

Knowing how important this promptness is, we built a question-asking feature into PMRobot, it gently follows up by email, and allows a response to be sent back via email.

7. DO Have additional work spec'd and queued up

Inevitably, some tasks are bound to be stalled due to unavoidable circumstances. Have other work ready to go for when that happens. If you're using an agile project management methodology like Scrum or Kanban,  you must be disciplined about having your tickets, or stories, planned and ready to go in advance.

The Don’ts:

8. DON'T email file attachments

This common practice is without a doubt THE fastest way to create mass confusion and ensure that you spend a lot of time digging through your inbox searching for version-control salvation.

This is why we use Google Drive to make changes and add comments within a single, shared document - it’s simple. Dealing with files appended with “-r2”, “-rev3” or “-jm-edit4” is frustrating and it’s rare that anyone actually goes back to the old files for reference.

Keep everyone on the same page, literally, by avoiding unnecessary version-control issues with email attachments.

9. DON'T interrupt people unless absolutely necessary

The biggest advantage of working remotely is the ability to work uninterrupted and make your own choices about when to focus on the work and when to delve into communication with your team members.

If there is something you need to get clarity on and need higher bandwidth voice communication for, use a chat tool to set up a time to talk on the phone. This has the additional benefit of letting people prepare, instead of having to suddenly switch gears for an unexpected call.

When in doubt, practice a little role reversal in your head. Would YOU want to be interrupted for this specific topic or could it wait?

10. DON'T bring in more people than necessary on conference calls

Meetings are rampant and massively time consuming. Play to the strengths of being distributed and let team members focus on their work. If a meeting needs 20 minutes, schedule it for 20 minutes, not 30, and respect that time allotment. If a participant on a call has said their piece and is no longer needed, let them drop off. Otherwise, you're wasting their time, and draining their energy to listen in on an irrelevant call.

To pull this off, set a timer on your phone for ten minute increments. Each time the timer goes off, look at the attendee list and see if anyone can be spared.

11. DON'T let roadblocks hold up the project

Overcoming roadblocks is a high priority. It’s tempting to move on to a new piece of work, and in rare cases, that’s all that can be done. However, focusing on pushing through roadblocks helps limit the work in progress and actually get things done more effectively. If there is a project manager or product owner, let them know as soon as you've done all you can to move forward, so that they can begin clearing the block.

PMRobot lets you mark a blocked ticket once you’ve done all you can for the time being, letting you move on, but keeping it present and within view so you remember to resolve the issue as soon as possible.

12. DON'T send emails when you're angry or frustrated

Queue them up as a draft, wait an hour, then edit. Delay again if you're still angry.

Negative emotions can be one of the most time-consuming and inefficient time sucks, and anger inevitably clouds your better judgement. If you’re writing it in an email, then it’s not urgent, right? So stop staring at it and thinking about whether or not to hit send. Walk away from it for an hour.

Depending on your disposition, you may have to repeat this a few times. Just remember, it’s better to err on the side of caution. You’re less likely to regret a witty retort you didn’t make, than an offensive email that gets BCCd to all of your upper management and HR.

And Finally:

13. DON'T do it all in email

You may have noticed a recurrent theme in this article; encouraging you to find alternatives to email when possible. DO NOT keep your email client open at all times, this is the best way to spend all your time reacting to outside forces and wonder what you got done at the end of the day. Email is in many ways the lowest common denominator for communication. Consider who you’re emailing and for what purpose - and then consider your alternatives.

Used properly; however, email can be very powerful, allowing you the time you need to express your ideas clearly and pull together all the links and other information needed to get your point across. Make sure you’re writing clear emails, use numbered lists/bullets more often than paragraphs and when it gets really long, write a short introduction so the receiver knows what they’re about to wade into.

Email is just one of many tools on your program management communications tool belt - prove you are a true master of project communications by knowing when NOT to use email as your most effective strategy.

The Benefits of a Project Management Tool

Using a web-based project management tool is one way to minimize your email use. A tool will often allow you to split your conversations into smaller pieces that are directly related to a specific piece of work, which can then be referenced when it comes time to do that work. PMRobot is been designed and developed Syllogistic Software, a team who've been working remotely for more than five years, living in Toronto, ON; Victoria, BC; Austin, TX; New Zealand, Thailand and wherever else we feel like working from.

For digital agencies and software consultants looking for a solution to your remote working challenges and want clear communication, faster execution and happier clients, visit PMRobot.com now.

- 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.

The First 100 Days in a new Project Management Role

Like the foundation to a building, the first one hundred days are extremely important to success in a new project management position. As a project manager, you're placed in the middle of many people—higher level managers, clients, and other staff; it takes extra effort to get off to a good start so that you can succeed in the long run.

Take it in…but keep shipping

A new company is a new cultural landscape to navigate. You must seek to understand it so that you can thrive within it. Every organization has its own peculiar DNA: a philosophy around decision making and a set of values that prioritize some actions over others. Pay attention to the language of your company’s leaders to identify those values.

It is essential to respect this time to observe and adapt to your new surroundings. At the same time, most of our readers are working in small teams where there's no room for dead weight. You'll be expected to keep your team producing without too many hiccups. This is the balancing act; breathe it all in, but don't stop the forward motion.

Improve the process by shipping

The organization that you've just walked into may be a well-oiled machine or it may be a war zone. Unless you're specifically mandated to begin process improvement immediately, keep your focus on shipping. This can be difficult, given that PMs love process. Among their kind, they can go back and forth endlessly about the best tools to use, the best ways to run meetings, and the best workflow processes.

Steve Sinofsky, former President of the Windows Division at Microsoft has an entire blog, with lengthy essays dedicated to the value of Learning by Shipping.

Never forget though that process exists to aid in the efficient creation of a great product. Keep things moving and observe keenly. Make small tweaks here and there to process and slowly but surely improve the lives of your teammates. With time you'll find yourself in a position to try out a new meeting format or introduce a new project management tool.

Serve your team and the work

Project management is not a glorious position; hopefully this isn't a surprise to you. When things go wrong, you'll take the blame; when you succeed, the accolades necessarily go to your team. Your teammates, the programmers, designers, copywriters, and analytics technicians are the experts. Your true job is to facilitate their collective brilliance toward creating great work.

All too often, managers behave as if a company exists so that they can be managers. Wrong. The purpose of your company is to do the work that it was made to do. You don't have to be subservient or obedient, but you must put yourself in the service of the work, and the people who do it.

Conclusion

The first hundred days in a position are absolutely crucial to your success. You're building your foundation, and there's a balancing act to maintain. Take the time to understand your new surroundings, don't stop your team moving, and most importantly, understand that your purpose is in service to the work that is to be done.

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."

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.

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

You can't assign 1 task to 2 people

This is one of my biggest pet peeves with certain project management software packages out there.

You cannot assign one task to more than one person!

And yet there is tons of project management software out there that lets people adopt this bad practice. Have you ever tried asking a group a question? It just leads to individuals assuming that someone else will take care of it.

You: "Hey team, Is the release going to be ready for Friday?"

Developer: "Well, I've done everything I can, but the client hasn't sent their logo yet."

QA Person: "The file interface is still buggy, but I'm not sure if I'm supposed to log bugs about that yet."

What's wrong here? There's no clear responsibility and no one owns the task.

Responsibility is key to all projects, and every task needs one person to be ultimately responsible for moving it forward.

This does not mean that multiple people can't collaborate and contribute towards the solution, but multiple assignment is often very dangerous.

Instead of both people taking responsibility, each one assumes the other one has it covered, and nobody takes any action.

This is why in most companies, there is a single CFO who is ultimately responsible for the finances or a COO who takes ownership of sales and operations. They would not be able to succeed without support from their teams and colleagues, but at the end of the day, they are responsible.

From the very beginnings of PMRobot, when it was just a simple ticketing system, we designed it to ensure that a ticket could only be assigned to one person at any given time.

This leaves no chance for ambiguity or misunderstanding about who needs to get what done.

If you want to increase your efficiency and reduce the number of things falling through the cracks, make sure you only assign things to one person.

Hard deadlines motivate people

The vast majority of people seem utterly incapable of doing anything until the very last minute.

Procrastination appears to be human nature, and tends to defy the best project management practices.

Whether learned or inherited, it's a very real phenomenon that project managers need to deal with on a daily basis.

Some managers try to jumpstart things by setting a "fake" deadline, a week or two before the "real" deadline, so that people actually start working on things and discovering unknown dependencies and challenges before it's too late.

This tends to work -- about once.

Then everyone clues into the trickery and ignores the next "fake" deadline completely.

Nonetheless, I've found that if you want something done, you need to set a deadline, and make people very aware of it.

In PMRobot, we've added a bunch of cues to remind people about deadlines.

The "Due in X days" text turns red at the 3-day mark. Ticket subjects turn bold and red at the same time. Reminder emails are sent out.

In project management, there's no easy way to fight the tide of procrastination, but I've found that it works best to:

1. Set a realistic due date. Make sure people know what it is.
2. Enforce the due date. Ensure that people know the consequences of missing it.
3. Communicate about the due date. Ask people regularly about their progress.
4. Don't push back the due date. Deliver on time, create a new milestone, and reschedule the missed work items.

How about you? What tools do you use for motivating people to keep on track?

Is email draining your productivity?

Mark Suster recently posted an article about "Why Email May Be Draining Your Company's Productivity."

Although I agree with some points, like batching email:

He suggest you never check first thing in the morning. He also suggests you only check periodically and leave your email off at other times so as not to be disturbed.

...I don't agree with this:

“I would far rather give out my mobile phone number than my email address.”

The good thing with email is that you can shut it off. I like to reserve my cell phone for urgent, time-sensitive communication.

Email, meanwhile, can be batched and processed when convenient.

And not all of it needs to be responded to. You don't really need to reply with "Thanks Bob" when Bob sends you the attachment you asked for.

So is email draining your productivity?

Probably, but there are some straightforward ways to be more effective. I wrote about "How to get people to respond to your email" a while back and suggested:

• Make emails as short and concise as possible.
• Write a concise, relevant subject line!
• Separate your short sentences into paragraphs with a space between them.
• If you are making multiple points, or asking multiple questions, put them in a numbered list.
• Edit your emails multiple times, and cut out unnecessary words and sentences.

Then on the other side, batch process your emails, as Mark (and Tim Ferris) suggest.

Hopefully those tips will help you tame the lion that is email :)

Communication: Keep your team small

A common mistake when projects are running late is to add more people.

This is often a disastrous mistake.

Often called "Brook's Law", Fred Brooks stated in The Mythical Man Month that "adding manpower to a late software project makes it later."

I've written about this twice before when explaining how building software is not like building a house.

A key reason for this actually comes from the PMBOK, and has to do with communication.

One of the formulas you must learn when studying for the PMP certification is the following:

For N people, the number of communication channels is (N^2 - N) / 2

This means that the number of communication channels increases exponentially with a linear increase of team members.

I'll explain with a simple visual example. Consider a team of 4 people:

#Channels = (4^2 - 4) / 2 = 6

Now let's add two new members:

#Channels = (6^2 - 6) / 2 = 15

Adding just 2 people has added a whopping 9 new communication channels!

Technology and design consulting projects often require a lot of detailed communication, so you can see how large teams can get out of control quickly.

So keep your team as small as possible, and if you're running late, think twice about adding more people.

Want more? Be sure to subscribe to our RSS feed.

5 Project Accountability Tips

Where does the buck stop?

When you're managing a project, it stops with you.

Save yourself a lot of trouble by making accountability clear.

Here are five quick ways:

5. Be specific

Your team members can't read your mind! Think about tasks from their perspective and add as many details as possible.

4. Assign tasks to one person

If you assign a task to multiple people, everyone thinks someone else will handle it, and nobody does.

3. Ask questions to one person

Don't CC the entire team. Ask one member a specific question.

2. Ask one question at a time

People are busy. Make things easy for them. Send separate emails, or number your questions so it's easy for them to respond to each one.

...and the number one tip:

1. Keep track

As a project manager, you need to track all of your "open loops." When a team member agrees to do something, make sure it's tracked somewhere you can both access, so it's clear what they've committed to.

---

Anything I've missed? Let me know in the comments or by email: jhanley@pmrobot.com.