Project Management Tips from PMRobot

Getting Things Done for Project Managers

2013-07-05T04:03:00.002-04:00

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:

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.

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.

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

2013-05-31T02:34:00.000-04:00

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:

Use an Iterative development model, not Waterfall
Do enough upfront planning
Make realistic time estimates
Keep your team small
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

2013-05-24T18:29:00.001-04:00

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"

2013-05-15T11:57:00.004-04:00

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

A Guide to Effectively Managing Your Solo Software Project

2013-05-01T03:07:00.001-04:00

This article will help you create some very basic systems for managing your solo software project. It won’t help you decide what projects are good ideas, or successfully market your software, but following its advice will make you more likely to get to a finished product, instead of giving up in despair.

Who will find this helpful?

a hobbyist or pro using their spare time to build something they want

an entrepreneur building a minimum viable product for a business idea

a freelancer building a web or mobile app for a client

anyone who wants to learn by doing

I’m sure many people are already on board with the need for some systems to help guide the creation of their software, but I can literally hear some of your bloodshot underslept eye-balls rolling in their sockets and saying “processes and project management systems are for the office, this is just overhead that gets in the way of getting stuff done".

I beg to differ.

Why you need a system

Even a simple project has multiple moving parts. It may be that you’re capable of keeping track of them all, but that requires effort and costs you brain power, your most precious resource for software development. The reason for this is known as the Zeigarnik Effect:

The Zeigarnik Effect is the tendency to experience intrusive thoughts about an objective that was once pursued and left incomplete (Baumeister & Bushman, 2008, pg. 122). The automatic system signals the conscious mind, which may be focused on new goals, that a previous activity was left incomplete. It seems to be human nature to finish what we start and, if it is not finished, we experience dissonance.

The take home is, unfinished tasks will trouble your worried mind. Storing your tasks somewhere trusted and finishing them as fast (or faster) than you start them, will free your mind for coding. A simple system will serve this purpose, while introducing minimal extra effort.

1. Getting Started

It may seem obvious to you what your project is; but until you’ve written it down, and explained it to a few people, you can’t be sure that it’s well defined. Figuring out why you’re doing this project and what your goals are doesn’t take long, and will pay dividends down the road.

Create a one-page project charter to outline the scope, objectives and people involved with your project. Your charter should answer the following questions:

What are your goals?

Get high level, ask yourself WHY you’re doing this, and what success looks like. If it’s a freelance project, establish this with your client. If it’s a side project, by straight up about it. Are you developing a minimum viable product to test a business idea or is it just something you think would be cool to see or make your life easier.

Who are the stakeholders?

Whose input is important to guide your project to success? Maybe it’s just you, maybe it’s potential customers or a client. How will you communicate with these people? How much influence will they have?

What will the product enable you to do?

This is akin to an epic user story for your product. Don’t talk about how the product will do what you want, focus on what you want.

A basic user story format is: "As a <role>, I want <goal/desire> so that <benefit>". This keeps the focus on solving the problem and avoiding tunnel vision around specific features for solving the problem. For example the epic user story for your product might be “As a bowler, I want to know how what I eat for breakfast correlates with my bowling score, so that I can always eat the right pre-bowling breakfast”

How much time are you willing to spend on this?

Particularly if this is a side project, it will almost inevitably take longer than you think. At the outset, we tend to see the work breakdown at very low resolution. Once you’re face to face with a particular task, you see the fine details and nuances much more closely. In one of the most popular quora answers ever, Michael Wolfe deals with the reasons for this very astutely.

When it’s no longer fun and exciting, will you keep plugging away, or will you accept the sunk costs and move on? Decide beforehand how far down the rabbit hole you’re willing to go.

2. Doing it and Managing it

Planning

Since you’ve already created a scope now you just have to break it down into manageable tasks, ideally things which aren’t much more than what you can do in a given evening or two worth of project time. Keeping your tasks small will help you to see your progress and feel great when you check something off.

Tasks that are further down the road, will inevitably be more ambiguous; no problem, as they come closer to being executed on, you can split them up further.

Write each of these tasks on a sticky note, we’re going to use them to fill up your personal kanban board.

Tools

The Kanban Board

Find a visible place in your workspace and put up a whiteboard. Keep your kanban board really simple with three columns: Backlog, Doing and Done.

There are two simple rules for using personal kanban:

Keep your work somewhere easy to see

Limit your work in progress. Typically no more than 5 tasks at a time in the “Doing” column.

Both of these rules would make Zeigarnik happy; they ease the burden of how much you have to store in your limited grey matter and put it somewhere you can trust you’ll see it.

Even when there is extra space in your “Doing” column, have a bias towards finishing a task over starting a new one. Only introduce new tasks into “Doing”, if everything else is stalled, and there’s absolutely nothing you can do to move it forward.

If you’re waiting on a domain transfer, go ahead and start working on wireframing. Don’t create a separate column for stalled or waiting items, even if you’re not working on it right now, it’s occupying precious brain cycles.

Time Tracking

No one likes tracking their time, and most time tracking software makes the process even less fun, but if you keep it simple, it can help to give you very valuable data and improve your sense of how long a task really can take.

Use your personal kanban to track when you moved a task into “Doing”, when you moved it into “Done”, and how many hours you spent on it. You can do this just by writing it on your stickies like so:

Setting up these tools adds minimal extra time to the initiation of the project, and will pay huge benefits by releasing your mind from having to track all these items and allow you to focus on the execution.

Wireframing

I do believe that wireframing and mapping out the workflow of your product are very much worth your time. We use Moqups, which is really user friendly and takes no time to figure out.

Version Control

Even though it’s just you, using version control will help you to undo your mistakes and create an easily trackable history of your progress.

Git Immersion is a great tutorial for setting up a git system. If you want a cloud based repository, with pretty graphics illustrating your branches and merges, Bitbucket’s free plan should be totally adequate for you.

Execution

Here’s the fun part, I hope that creating the charter and setting up your tools only got you more excited about the awesome code you’re going to write.

This is your project, it’s not my place to tell you which languages, frameworks and other technologies to use, you know what works for you. Unless this is a project intended to help you learn some new technologies and frameworks, you probably just want to get going with the least amount of new learning required.

Scope creep is the great enemy of getting things done. If your imagination, your client or other stakeholders are introducing new and wonderful features to distract you, nip that in the bud. This is why you created your project charter. Keep it beside your Kanban board, where you can see it and remember what you’d first set out to do. If the project drifts from the charter, make sure there’s good reason for it.

Keep moving, do what you can to make some progress every day to stay motivated.

3. Releasing 1.0 and/or Closing

Maybe you release your 1.0 and this project blow up into a huge success and becomes your life’s work. Or perhaps you’ve met the goals of your original charter, but you see potential to go further.

On the other hand, maybe you’re completely done with this piece of software; it’s served its purpose of satisfying a client, or teaching you what you set out to learn, or is now serving you as a handy little tool.

Either way, upon completing the first version of your project, it’s worth doing some work to close it out. The scale of this effort really depends on the project.

At a minimum, you should archive your post it notes somewhere safe. When starting your next project, they’ll be useful for remembering what tasks and time commitments were required last time.

Now sit down, have a beer, and contemplate how awesome your shiny software is.

From D.A.K Photography

References and inspiration:

https://news.ycombinator.com/item?id=4910022

http://pm.stackexchange.com/questions/195/minimum-project-management-practices-for-one-man-software-projects

http://stackoverflow.com/questions/1523418/single-person-application-development

http://kiragiannis.com/business/10-tips-to-guarantee-success-on-solo-projects/

- John Mardlin

The Truth about PMRobot

2013-04-12T08:30:00.000-04:00

I was just in San Francisco on a business development and learning mission for PMRobot. It’s amazing how deeply integrated the culture of entrepreneurship is there. People ask a lot of good but tough questions. Of course, answering tough questions is the best way to get better at explaining our company, and how we can help software and design consulting companies to manage their projects better.

This has me thinking about the general business culture of exaggerating their strengths and covering up their blemishes.

Marketers Lie

You may not even think about it, but you've probably learned to approach most marketing with skepticism.

I’ve always been a terrible liar, of course it’s not something I’ve ever aspired to be. It feels though, that in business, and marketing especially, it's standard operating procedure to exaggerate in order to look bigger than you are. I recently watched an excellent talk by Jason Cohen from the Business of Software conference in 2011. He talks about the importance and value of being honest about your product's strengths and weaknesses. I’m putting this into practice by being brutally honest about our product in conversation with people I meet. I want to take it a step further by putting it online.

The Benefits of Honesty

People are accustomed to falsehoods and half truths in marketing materials.

They've developed an automatic filter:

Say you’re the market leader in something? “Yeah, right!”
Fill your site with nothing but unabashedly positive testimonials? “As if!”
Act like you’re a huge company (when you’re not)... people will see through your act.

I could make a high-minded, moralistic argument for honesty in this article, but I believe there’s also a sound business case for honesty.

My experience is that people find honesty refreshing, even disarming. By being upfront about your shortcomings, you give them a reason to trust your claims about your strengths.

Honesty, also makes you more human and relatable. It makes you the kind of people others want to see succeed. It opens you up for receiving honest feedback, which is essentially to any lean startup.

So let’s be honest about PMRobot. I'll tell you who we are and our story. By laying it all out on the table, you’ll know what you can expect if you choose to do business with us as a customer.

How was PMRobot Started?

PMRobot was started by Jason Hanley. He’s been running Syllogistic Software for a decade, and during that time, he’s managed his business from several distant corners of the globe. For the past 5 years, he’s been building a tool to help him manage his projects, employees and clients. This tool eventually became PMRobot, a tool to help consultants manage all the aspects of their projects.

Who is PMRobot?

The PMRobot team is still quite small, the development efforts on PMRobot are provided by Jason and his team of programmers at Syllogistic Software. I handle the marketing, blogging and engage with users to find out how we can make the product better for them. We’ve recently brought on Michele Macklin to help us improve our interface and user experience design.

We're passionate about agile and lean project management and productivity. We believe we can help digital consultants adopt agile project management more effectively.

I’m thankful to be working with such talented individuals on a product that I believe in.

OK, What is PMRobot?

PMRobot is project management for software consultants. It was built by software consultants, and it works best for them and similar companies like internet marketers, app development consultants and digital product companies.

The product is very feature rich. In fact, PMRobot has so many features that it can be overwhelming to new users. However if they take the time to learn how to use the product, they’ll often find that it meets their needs really well.

Our product solves some problems better than others. One of its strengths is bringing together multiple tools into one system, such as workflow management, time tracking and client communication.

Some areas that we see opportunities to address real needs for our customers are in helping with human resource allocation across different projects and understanding the costs and profitability of different projects. Feedback from our users is hugely valuable to us, and it’s what informs our decisions about design and new features.

Why would you want to use a new and unknown app in your business?

Maybe you shouldn’t, it depends what you’re looking for.

We might be a good fit for you if you’re a software consultancy or digital agency, looking for something built to address the particular challenges of including clients in running your projects. You’d be an early adopter and you’ll get to experience working with a product that is evolving, both aesthetically and functionally. T

The benefit of this is that you’d be part of a community of companies using PMRobot and helping us to build a tool for a very specific group. If there’s something specific you’re looking for in a software tool, talk to us, and we’ll consider building it for you.

If you just want something really simple to use out of the box, and are OK with it not being so feature rich, we’re probably not the right product for you.

If you want to be a small customer for a big company, with dedicated 24/7 customer support, PMRobot isn’t the right product for you. But if you want to have a real relationship, and the ability to speak directly with the people building your project management tool, then you’ll appreciate working with us.

If you’re worried that we’re a new startup, and might not be around a year from now, don’t. Syllogistic Software has been around for 10+ years, we’re in this for the long haul.

Still not sure if PMRobot is right for you? Leave a comment and I’ll be in touch with you to discuss, or try us out. - John Mardlin

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

2013-03-13T09:00:00.000-04:00

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

The New Marketing: Agile, Lean and Loving

2013-03-05T14:31:00.000-05:00

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

Friendly new conversation view in PMRobot

2013-03-04T09:00:00.000-05:00

PMRobot is just a tool which helps you get your work done. It shouldn't get in the way, and it shouldn't add a layer of separation between you and your collaborators. We've made a simple, but we think significant improvement to the conversations interface to emphasize the human element of your interactions.

Bigger faces and a clearer indication of who said what should make for a smoother reader experience.

Take a look:

Old and Busted Conversation View

New Hotness Conversation View

If you're new to PMRobot, and looking for a solution to help your team collaborate, try it out. One project is free forever.

- John Mardlin

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

2013-02-28T08:45:00.000-05:00

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.

Agile Families: a TED Talk by Bruce Feiler

2013-02-27T17:21:00.001-05:00

We're seeing the spread of Agile into so many new areas, the world is looking more an more agile all the time.

This recent TED talk brings the idea of Agile to the family, and promises to empower children the way it has workers. Which Agile practices is your family using, and what's working?

Answer Questions in PMRobot Right from your Inbox

2013-02-24T18:13:00.000-05:00

We know it's important not to create friction between you, your team members and your clients. Our aim is to build an agile project management tool that gets out of your way instead of adding overhead.

One of PMRobot's most popular features is Question Asking in a ticket. It makes it easy to get the answers you need to move forward, and it puts them right where you need them. Until now, the only problem was that you needed to go to the app to answer a question. Not the worst thing in the world, but it does interrupt your flow when you're responding to other emails.

That's why we're adding our Email Reply feature. Questions asked of you are delivered to your email inbox. To respond, all you have to do is reply as you would to any email. The answer will appear in the ticket and the question will be recorded as answered. Forgot to mention something? No problem, another email reply will simply be appended after the first.

Go to PMRobot to try it out with your team members.

Antifragile Project Management

2013-02-21T12:23:00.002-05:00

What We Can Learn From the “Farm”

A favorite parable within the Agile community is “The Tale of the Chicken and the Pig.” In the tale the Chicken suggests to the Pig that they start a breakfast joint together, pooling their resources to serve ham and eggs. The Pig is understandably reluctant, saying "I'd be committed, but you'd only be involved..." The story helps to distinguish between the stakeholders who do the work (pigs) and those who are only interested in, and supportive of, the success of the project (chickens).

Another useful farmyard parable is the tale of the Turkey, a favorite of Nicholas Nassim Taleb’s. Taleb’s book “Antifragile” is a deep investigation into systems that gain from chaos and disorder.

And thus begins the story of the Turkey:

Each day, the Turkey is fed a delicious meal by the Farmer. As surely as the sun would rise, she received her satisfying meals with steadfast regularity. Diligent, she did her research, reviewing her KPI with the appropriate experts, and her confidence in the Farmer’s reliability steadily increased as did her quantity of feed. Naturally she predicted that the trend would continue…

Of course, we know better than the Turkey; come Thanksgiving, shortly after receiving her largest meal of all time, she met an unexpected end.

In project management sometimes we know as much about our big chaotic world as the Turkey knows about the Farmer's intentions. The Turkey believes that she has adequate information to predict the future, much like the implicit assumption behind Waterfall methods where the initial "plan" dictates the final product.

Relying on a specific plan can blind both poultry and project members to new opportunities that arise. While the Waterfallists are busy tracking how far off schedule they are, the Agilists have noticed that half the stuff they’d planned isn't what their customers want.

In industries where problems are open ended, like software, marketing and design, we must acknowledge that we don't know everything at the outset.

Know your pigs from your chicken’s and don’t be a Turkey. Be antifragile by being agile: develop your teams culture, processes and mindsets so that you can adapt quickly when things don't go as planned.

Acknowledging the unknown is halfway to anticipating and overcoming the unexpected.

The First 100 Days in a new Project Management Role

2013-02-13T12:51:00.001-05:00

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.

Too much going on? No problem, you can sort it out.

2013-02-08T00:32:00.000-05:00

Now it's easier to get your priorities in order

We're always working to make what's already a great project management app even better and more user friendly.

Now you can spend less time managing and more time getting things done.

Drag and drop your tickets anywhere in the queue

You no longer have to click arrows to move the ticket from one column to the next. The updated sorting saves time, and makes it much easier to get everything laid out in just the right way. If you haven't seen it, take a look: https://pmrobot.com/tickets/sort

About PM Robot

PMRobot keeps everything in one place, making your job easier.

No more information scattered across 7 different tools.

With PMRobot, there's only one tool to learn, and one place to search for all your files, tasks, and project information.

Questions or ideas? Contact us at http://feedback.pmrobot.com/

- John Mardlin

6 way to make your clients love you while staying sane

2013-02-04T15:15:00.000-05:00

You work hard to get your clients. All those calls, conferences and coffee meetings aren’t just for fun. So you’d better take care of them once you have them. It may seem burdensome at times, but the effort invested in strong relationships and doing great work will pay back in growth opportunities.

In their book “Leading on the Edge of Chaos”, Emmet C. Murphy and Mark A. Murphy state that a 2% increase in customer retention has the same effect as decreasing costs by 10% . Making clients happy is one of the best ways to grow a business. They'll spread the word for you so you can spend less time selling, and more time doing great work.

Build your business on these 6 pillars to keep your clients and grow your business:

1. Make honest and realistic estimations of timelines

We all do it, and it happens in every industry. At the start of a project, you’re feeling good and you know the finished product is going to be great. You’ve made a list of everything involved, and you’ve guesstimated how long each piece will take. This is where things get dangerous. We can be tempted to over-promise when entering into a new relationship, but over-promising does not create sustainable relationships. Set realistic expectations for your timelines, and give yourself some padding for bumps in the road. Because even when you think you’re almost done, you’re probably not.

2. Be a great communicator

Find out your client’s preferred method of communication and use it. If they leave you a message, don’t email, call them back. Make sure your clients know what's going on, before they start to wonder about what you’re up to by providing them with regular updates on a schedule that makes sense for the project. Be especially conscious with formal reports; make your reports concise and understandable, use agreed upon metrics for success, and use visuals when possible.

3. Be Respectful

Your client may not have the same level of expertise that you do (that’s why they’re paying you), but they’re smart enough to know they need you. Take the time to educate them in how you work and what processes you use. Steer clear of jargon; cut down on the three letter acronyms that you throw around casually with your colleagues. Instead, pay attention to how your client speaks, and build that language into your conversations with them.

4. Agree on what success looks like

Doing work that makes your client happy requires great empathy. From the beginning, you need to understand their needs, and get a clear picture of what you're working towards. Once you think you know what you're building, tell your client what you'll be doing. Agree on what needs to be delivered, and how that will be measured. It takes more work upfront, but getting everyone on the same page creates a lot of trust. This trust enables you to do the work, without being constantly pestered. The extra effort at the beginning makes you far more likely to deliver a great product.

5. Set boundaries

You want to keep your clients happy -- that’s why you’re reading this article. You want to reach new heights, diveak down walls and meet stretch goals for them. But remember, they’re looking to you not just to do some work, but also for leadership and guidance. This means letting them know when their ideas won’t work, and not giving in to every demand. If they insist on a change, let them know, in writing, how their request differs from the original scope, and how you expect it will impact the project.

6. Do great work

Obviously! Of course you do great work, you always put your best into every project and sweat the details, right? Great, but not everyone does, and time saved by cutting corners could end up costing you many times over in rework and damaged relationships. By all means, extend yourself, take on big projects and grow, but be sure that you're willing to do what it takes to delight your clients with the finished result.

We can take another great statistic from Murphy and Murphy’s book “Leading on the Edge of Chaos”: organizations that prioritize the customer experience generate 60% higher profits than their competitors. With the rise of social media, people increasingly rely on word of mouth and reviews to make buying decisions. It becomes a virtuous cycle: This means doing great work and making clients happy can be an excellent marketing strategy, which means you can spend less time selling, and more time doing great work.

New Inline Quickedit feature

2012-12-09T14:30:00.000-05:00

Here at PMRobot, we're always looking for ways to reduce the number of clicks.

We call our latest improvement the "Inline Quickedit".

To use the Inline Quickedit feature, simply click or tap a field in the List view:

You’ll be presented with a touch-friendly pop-up to quickly select the field:

Two clicks and you’re done!

This feature currently works with:

Ticket Type
Priority
Effort
Milestone
Assignee

Even easier...

2012-11-05T19:19:00.000-05:00

After carefully listening to our users' feedback, we've launched an update of PMRobot that's even easier to use.

So what's new?

1. Project selector with search

Now you can find your projects quickly with typeahead search:

It's placed prominently at the top left in a large font, for easy access.

2. All your settings in one place

You said: "I can't find my settings!"

We listened :-)

No more hunting around. They're all organized in one place now. Just click More... Settings.

3. Hide unwanted features:

You said: "My screen is cluttered with things I don't use!"

We listened.

Too much clutter? Clean it up by turning off the features you don't use!

Organization primaries can change this at https://pmrobot.com/organization/info

4. Feedback and Knowledge Base

Have some more ideas for us? Not sure how to do something?

Check out our need feedback and knowledge base at:
http://feedback.pmrobot.com

Waterloo Region Infographic

2012-08-13T08:25:00.000-04:00

This week we have another great infographic. This time about PMRobot's hometown -- Waterloo, Ontario, Canada.

Sortable has put together some great stats about the region:

You can click the graphic for the original article at Sortable.

Perils Of Multitasking infographic

2012-08-09T11:16:00.000-04:00

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.

New: Clean and simple navigation

2012-07-23T05:20:00.000-04:00

PMRobot has a great new menu and navigation system!

We've always had the most features, but sometimes it's been a bit difficult to actually find them. :)

Those days are over.

Everything is now right at your fingertips.

We've crunched through over a year of logs and statistics to determine the most frequently used pages, and put them right up front.

The less popular (but equally useful) pages have been moved to a secondary menu.

They're still easy to access, but don't get in the way of your day-to-day work.

We've also improved the "quick submit" box by moving it to the left and sprucing it up:

...and don't forget -- PMRobot works great on mobile devices like smartphones and tablets!

We hope these improvements help save you even more time, and make your day just a bit more pleasant :)

We're continuing to work hard every day to make PMRobot faster and easier for you.

What do you think of the new navigation?

Take a vacation from project management!

2012-07-09T12:43:00.000-04:00

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

Drag and Drop Sorting + Gantt Charts

2012-07-02T06:06:00.000-04:00

This week we introduced two great new features!

Now you can spend less time managing and more time getting things done.

Drag and Drop Sorting

Instead of dealing with the abstract notions of high, normal, and low, we now use the Agile concepts of Current, Backlog, and Icebox to give an indication of the order in which groups of tickets will be worked on.

Within these main priority levels, you can simply drag tickets up and down to fine-tune the exact ordering of individual tickets.

Try it now at: https://pmrobot.com/tickets/sort

Gantt Chart

This week we also introduced a new beta feature: the Gantt Chart.

A Gantt Chart gives you a quick, visible overview of upcoming milestones and resource allocations.

You can also see at a glance which tickets have not yet been assigned.

Give it a try right now at: https://pmrobot.com/chart/gantt

Don't forget...

PMRobot keeps everything in one place, making your job easier.

No more information scattered across 7 different tools.

With PMRobot, there's only one tool to learn, and one place to search for all your files, tasks, and project information.

Questions or ideas? Contact us at https://pmrobot.com/help

About the author: Jason Hanley slaves tirelessly, spending his days and nights devising new ways to make software project management faster and easier. While PMRobot is managing his projects, he enjoys riding camels in the Sahara desert, teaching English in Spain, and exploring the south of France.

How to: Manage Remote Projects

2012-06-18T09:30:00.001-04:00

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:

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

So what tools did I employ to help the situation?

Email
Conference calls
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

Removing the Mailman

2012-06-04T08:14:00.003-04:00

When I started working at Syllogistic Software, all client communication went through my manager. They knew him, he knew them, and it was simpler that way. This worked great for about 30% of the emails we sent because they were managerial questions, like getting estimates, talking about features, and scheduling work. Once all that was done, it fell to the developers to actually do the work, and interpret the clients’ requests. And sometimes it wasn’t 100% clear what they wanted.

Enter the mailman. I would write up a question about something that we didn’t know, then my manager would look it over and then email it onto the client, usually verbatim. Then the client would respond to my manager, and my manager would forward the information back to me. Much of his "work" consisted of simply passing notes between the two sides. It was ridiculous!

This story was a big driver behind how we designed PMRobot. We wanted to have clients use the system, and communicate directly with developers, so that our manager didn’t have to be a mailman as well. This change also sped up how quickly we communicated with clients, allowing us to get answers within minutes, instead of hours, or even days. Now that our manager is travelling in Europe this is especially important. He’s no longer a bottleneck, and we don’t have to worry that “the answer is in the mail”. :)

About the author: Travis is a programmer for Syllogistic Software and helped build and design PMRobot.