Work Management

Yesterday I posted The Social Project Manager. Anna Evans posted a great comment:

"Your point of view has great conversation opportunities. I would love to hear real world application stories and experiences. Would you think this process would lend more success to consultants and out sourced PM?"

Thanks for the comment, Anna. Great question. I started to reply and found myself basically writing another blog post. So here goes:

The first time I really used this approach was about 5 years ago. I was hired as the PM for a project to develop a new website for a city. Since I had worked on projects like this before, I knew what kind of people I needed. I selected a team of the business analysts, developers, IT experts, and testers that I trusted.

As I initiated and planned the project, I involved them at each step along the way, including contract negotiation, charter development, scoping, and scheduling. Sometimes they were there in meetings with the stakeholders, sometimes I consulted with them offline, and sometimes I simply kept them in the loop. Involving the team in that process engendered trust—I understood their perspectives/concerns, and they appreciated the challenges and reasoning behind initiating/planning the project. Most importantly, everyone had a greater sense of ownership that motivated them to personalize the plans and work they committed to. I felt like my plans were more realistic and bought-into.

Very early on, I set up a collaborative online project workspace that everyone—including sponsors and external stakeholders—had access to. Every detail of the plan, from milestones and real-time status to meeting minutes and comments on issues, it was all visible to everyone. Once the project was started, we made public a test server that always had the most recent build from the development machines. Everyone could see the state of the website as it was being developed.

The stakeholders and sponsors were almost giddy with that kind of visibility. They could see our productivity as clear as day. They could appreciate the progress we made every day, and they felt like they were truly a part of the project, because they could see and comment on the progress. That level of visibility also motivated greater team productivity. It was impossible to hide performance—for better or for worse. There was a natural gravitation toward efficiency and results.

Regular and ad-hoc meetings over the phone, via web-conference, and in person helped to expose problems quickly and encourage changes that removed roadblocks or leveraged unique opportunities. There was little need for the traditional project status report—the sponsors and stakeholders knew where the project was going in real-time and were able to voice their concerns at any time—thus helping us to know their concerns immediately and address them before we got too far down the road.

As a team, we were flexible and extremely efficient. I was less of a political head or commander, and more of a facilitator and enabler - I lived to serve the team and make things easier for them. I coordinated and guided, while the team collectively owned the plans and execution from start to finish, which better aligned plans with reality and ensured that the team was totally committed and accountable.

Since that project, I have done my best to incorporate those principles. And to the extent that I have followed (and have been able to follow) the principles that I outlined in my post, I have been successful.

You asked about whether these philosophies better serve a consulting situation. Based on my past experience, I think your generally right. But the reason is not necessarily the organizational environment, it's more about the cultural environment.

I've also been a project manager in matrix organizations where traditional approaches were the expectation. I was able to incorporate some of the principles of social project management, but like I said in the post, there were aspects of the approach that were like oil in water, so I adapted my approach to suit the culture.

The organization I'm working in right now (AtTask), is matrix, but more progressive. We are able to implement virtually all of these principles. In fact, our executive team encourages them. We have our obstacles, and we continue to refine our approach, but I have felt (and I think I can speak for my teammates) that it really works for us.

As a final note, we spent a great deal of time last year doing research, visiting a wide variety of organizations around the US. We were looking for how projects—how work—really gets done. We were looking for inefficiencies to solve and innovative ideas/opportunities. Our observations led us to the approach that I outlined in this post, which was interestingly familiar.

I hope I've answered your questions, Anna. If not, or if you have further questions, comments, ideas—I hope you'll share.

For anyone else reading this who has had similar experiences to mine, or if you have a different point of view, I hope you will share on this thread.

We are currently working on a new version of @task that is built on the principles of social project management. Some of my earlier posts refer to other aspects of these concepts.

If you're interested in learning more, check out our user conference in May.

Here's a buzz word for you: social project management. Most of the stuff you'll find on the web about social project management relates to social media being used as project management tools. But simply using a social media tool doesn't mean that you're practicing social project management.

Social project management is an approach to managing a project. It's about letting go of the top-down control of traditional project management. It's about empowering and trusting people. It's about an open-book policy that motivates people to perform.


Here are a few key attributes of the social project manager:

• Trusts the Team. Social project managers empower the team by allowing them to define their own approach and deadlines (given the project constraints). These bottom-up plans become the project plan. This means that the project manager is freed from being a task master and can focus on removing roadblocks and ensuring quality.
• Enables and Encourages Collaboration. Social project managers create an environment that facilitates communication between team members and teams. This may include daily scrums, collaborative software, paired task assignments, etc. The key to creating value and productivity is that each social interaction has the context of work.
• Focuses on Qualitative Data. The social project manager knows that there are infinite shades of red, yellow, and green. While some project managers focus on %complete, social project managers target the human element in a status report that reveals obstacles to be removed, opportunities to exploit, and the true state of the project.
• Broadcasts the Project. Social project managers believe that one of the best ways to engender stakeholder trust and to motivate performance is to make the project publicly accessible. Raw, transparent accessibility to project work and progress is frightening to the traditional project manager, but fundamental to the philosophy of social project management.

Some aspects of social project management resonate with traditional approaches, like relying on expert input to create the plan. Other aspects like broadcasting the project are hard for traditional organizations to swallow -- for various reasons. It's hard for some project managers to give up so much control. Further, some executives, given such granular visibility, can't resist the urge to micromanage.

Introducing social project management is more than using a wiki to store threads and documents. It's a cultural change that is felt from the executive level all the way down to the individual contributor. On the one hand, executives and managers will need to be more trusting of those in the trenches. On the other hand, team members need to step up to the plate and take on the accountability that such transparency demands.

Being a social project manager means changing the way you look at your team, your project, and yourself. Your role becomes more of an enabler than a controller. It may not be for everyone; but if done right, it can unleash the power of the masses toward the success of your project.

“We are judged by what we finish, not what we start.” — Anonymous


When people think of project management, they often think of what gets done in early stages to execution of a project: creating a project plan, task assignment, status reporting, change management, for example. What often gets overlooked — even by project managers themselves — are the key elements of closing a project.

When the deliverables are successfully deployed, the stakeholders are generally satisfied and consider the project complete — but is it? On the other hand, projects that fail come to a screeching halt and the project becomes a sore spot that no one wants to hear about anymore. In either case, once the execution of a project comes to a close, people tend to move on. This is when you see the true calibur of a project manager — when the project is closed.

Less effective project managers will be on one of two extremes. Either they will

1. simply drop all ownership of the project and forget about it altogether, or
2. spend time and resources in excess of what is necessary to close the project.

In the first case, you are shooting yourself in the foot. In the second case, you're beating a dead horse. When you don't take the time to close a project properly, you're likely to miss out on lessons learned, you may not have data easily accessible for audits, reports, or planning in the future, and (depending on the industry or nature of the project) you could even open yourself up to regulatory issues or even lawsuits. When you over-do the closure of a project, you incur unnecessary costs, annoy stakeholders, and may end up distracting yourself and others from organizational goals.

Here are some concepts that have worked for me:

1. Use good judgement. Take the time to plan how you're going to close the project. Depending on the scope of the project, this may require anywhere from 5 minutes to 5 days - or more. Make sure that you cover the bases, but don't overreach - stick to what is most important to the context (past project documentation and lessons learned can help out here). Be open and proactive in changing your plan as your project progresses.
2. Create a Closure Checklist. Once you've chosen your approach, make a simple list of things that need to be done. The checklist should be such that, when all items are checked off, the project can become history, and you can finally sleep at night.
3. Capture Lessons Learned. ALWAYS make a record of things that went well, things that didn't go well, and plans for improvement. The project can't be closed until the plans for improvement are either completed or added to a separate backlog of items that will be worked.
4. Leverage share-sites and project management software.  Too often project documentation is on someone's desktop, inaccessible (and therefore useless/non-existent) to others. Having everything in a centralized and accessible data store makes your closure process and future planning so much more efficient.
5. Get Sign-Off. Give key stakeholders the opportunity to approve the closure of the project. This can be as simple as an email or as formal as a closure meeting. However it is done, it is important to confirm that their expectations were met. Having said that, make sure that your charter is the guide for the definition of done.
6. Communicate Closure. Make sure the stakeholders know that you have closed the project. This is a good time to showcase the success of the project, or (in the case of a failed project) some of the key lessons learned. Just as in the outset of the project when you communicate the launch, you are accountable to your stakeholders to report closure of the project.

When a project comes to the finish line, don't forget to go the extra mile. Take the necessary time to tie off the loose ends and put things in order so that future projects can benefit. Don't miss out on the most important part of the race - crossing the finish line.

"To effectively communicate, we must realize that we are all different in the way we perceive the world and use this understanding as a guide to our communication with others."

- Tony Robbins




As a project manager, do you ever feel like you spend most of your time just getting people to communicate—whether it be to give you information, share updates, or work with each other?  I've heard this from time to time as I've worked with, observed, and interviewed various project managers. If you're a project manager and struggle with this, I have some ideas for you.

Don't waste time coming up with a carrot or a stick to get people to communicate to each other or to you. As a project manager, one of your responsibilities is to create a good communication strategy—an information system that will capture updates naturally. Creating this plan is not simply a matter of you deciding what works best for you.  It may not even be following what is already in place. Everyone communicates differently. It's your job to find out how your team and stakeholders prefer to communicate and create an environment and system that will facilitate easy flow of good information.

Voluntary information is the best kind, and you need to find out what will generate the most of it. Too often I hear project managers say that their team (or some member of their team) is just not giving the information they need as project managers to forecast, manage, and report.  While there are instances where workers may be less effective team players, I find that in most cases, there are lurking variables.  Either the project manager has done nothing to understand what makes that team (or team member) tick, or there is something that is obstructing the flow of information.

Take some time to understand your team and stakeholders. What are their key attributes?  What do they care about? What bugs them? How do they communicate with their friends? When you understand the preferences and nuances of each individual on your team and the pool of stakeholders, you can look for overlap and commonalities that will help you create an effective communication strategy. This includes not only the systems you use, but your very approach to communicating with them individually. If you get this, you will be amazed at how much more effective you—and your team—can be.

Communication can be negatively impacted by cultural, geographic, or other conflicts.  If your team is international, there may be obstacles from the time difference to the way people say and interpret things. Further, there may be disagreements or friction among team members or with the way you communicate. As a project manager, you are expected to perceive these issues and deal with them accordingly. Step up to the plate, confront and resolve discord through understanding and openness. Set up an infrastructure that will efficiently facilitate timely communication and interactions. 

Oftentimes, communication problems are caused (or at least compounded by) project management tools. Executives and project managers love the idea of getting work into a system that allows them to forecast, report, and make more informed decisions. But when these tools are difficult to use and/or complicated, they can end up creating more problems than they solve. Newer approaches to work management software are getting closer to solving this problem. But as a project manager, it is your duty to remove obstacles to ensure smooth and successful project execution. If some heavy PPM software tool is impeding your team's ability to work efficiently, then you need to have the guts to make a change.

I have found that the biggest obstacles I've come up against, as well as the most rewarding successes, have been closely tied to or a direct result of my communication strategy. The next time you have a communication problem, instead of blaming it on your team or circumstances, take a more proactive approach: consider your communications strategy.

"The most important thing about goals is having one."
- Geoffrey F. Abert





Sometimes we forget to take a step back and consider the big picture: objectives, goals, the point of what you're working on. Getting something done gives immediate gratification. But finishing something that wasn't driving toward the right goal can be a waste of time. And there are so many distractions along the path to success that can lead you off-course.

Scope creep is the classic example of a time-waster and distraction. Nice-to-haves and specials sneak into work all the time, and before you know it, you've overloaded your work with unnecessary baggage and sent yourself down a rabbit hole.

One of the keys to successful work management (in any setting) is to define your goals and keep those goals in mind as you work. This is especially true with project based work. Project and portfolio management are all about setting and achieving goals.

I have found enormous value in creating a charter for the projects I've worked on. A charter is a short document (I like to keep it to a page) that defines the purpose, constraints, and deliverables of a project. The charter acts as a guide for the project, setting boundaries to avoid scope creep and keeping everyone focused on what is most important.

As soon as I'm given a project, if a charter has not already been defined, I like to sit down with the key stakeholders and discuss the objectives, the constraints, and the deliverables. The discussion should not be too detailed. A rule of thumb that I follow is that the charter should be high-level enough that you should never have to change it throughout the project without calling into question the validity of the project as a whole.

Once we have agreement on the charter, I make sure that everyone (and I mean everyone on the team) has a copy of it and/or access to it through a share. Some agile teams keep their sprint goal at the top of their scrum board. In their daily meetings and throughout the sprint, that goal is right there in front of them. This helps keep everyone focused on the purpose of their work, and to guide discussions about scope. 

Applying these principles to product management has been helpful, too. Our team invests a lot of energy and time into making sure we have an agreed-upon, formal, and clear product vision. The overall product should have a driving vision, as well as each development effort as the product is expanded/improved. Having such a vision helps to avoid discord, waste, and scope creep — it keeps us on the path to success.

If you're doing this already, keep it up. If you're not, give it a try. I know it will make a big difference.

In my past two posts, I've discussed work management and the importance of the project team member in information flow. In this post, I want to share a slightly different perspective on the same theme: that of the project manager, who I call Jen.

Jen is a typical project manager with the typical project management struggles.  Information flow is key to her success and therefore the success of the project.  But much of her time is spent collecting information.  From estimates to assignments to updates to reports, information flow is hampered by a variety of barriers.

Once she has a breakdown of the work for the project, she emails out a list of items for estimation to various group leads.  Each of those leads has various other projects they're working on, so quite often she has to follow up several times to get a response.  Once she gets all of the estimates back, she has to enter them into the project management software.

After she makes assignments through the project management tools, she has to set up meetings to make sure everyone understands and commits to their assignments.  Once the project is in execution, she holds weekly status meetings to get updates and ensure cross-functional visibility.

Jen spends an enormous amount of time aggregating all of the information from email, notes, and meetings so that she can get it into the system.  She believes in the concept of enterprise project management software to improve work management, but project management tools are useless without all of the data from the trenches.  Since none of the project teams will use the software, she spends countless hours entering and massaging the data in the software herself.

Here are some possible solutions to Jen's data entry problem:

1. Jen could mandate (or get management to mandate) that the project teams use the project software. This works—sort of.  When people are mandated to do something they don't want to do, they only do the minimum required -- that means low quality data that is probably updated on a minimal interval, like weekly or monthly.
2. Jen could keep doing what she's doing. Eventually, she'll crack. Either she'll burn out or her lack of efficiency will cost a project's success.
3. Get work management software that the team members enjoy using. You may say "who enjoys using work management software?" You might be surprised. People spend at least 1/3 of their life working, and lots of those people (like you and I) do it using software. Anything that makes 1/3 or more of my life easier is definitely worth it—I might even call it enjoyable.  Think about how much time people spend customizing their desktop, adding plugins to their browsers, and making their email signature look pretty. They want control and comfort in their daily grind.

#3 is something that we (here at AtTask) are focusing on right now. We're tailoring each feature, each screen, each interaction to the user. Imagine a button for Jen that would with one click get an estimate from all of her project team members and automatically aggregate it into a reporting system.  Imagine an environment that naturally motivated team members to collaborate and voluntarily share rich information about their work—every day.  And what if all of this information were continually flowing into the system and generating analysis and recommendations? Stay tuned.

To learn more about where we're going with Work Management, come to our user conference in May.

Chris is a lab tech. His job is basically to test samples and report results. He doesn't manage people, doesn't make presentations in meetings, and doesn't plan too far into the future. Chris focuses on a list of things to do today and this week.

Marc, the CEO of Chris' company, is interested in reducing waste, optimizing output, and maximizing value. One of the initiatives toward these goals is to implement a Project Portfolio Management Software solution across the enterprise. His advisors tell him that "this investment will help us to track Project Based Work and give us the insight we need to ensure successful Portfolio Management."  Are they right?

Maybe, maybe not.  Enterprise Project Management Software is built for what it's name denotes—managing Projects and Portfolios.  These solutions are tailored to the project manager and the executive—someone other than Chris.   But Gantt charts, cost management tools, efficient frontier calculators, etc. are only as good as the data powering them.

Let's imagine for a moment, that Chris doesn't like using the Project Management Tool (hard to believe, I know). If his experience is bland, difficult, and irrelevant to him, he'll use it less often and only when he's forced to. The data he puts into the system will be the minimum needed to comply. For Marc, that paints a sparse picture of what's going on—and it's rarely up-to-date. Try steering a ship on minimal information that is out of date.

On the other hand, if Chris (and everyone at his level) finds value in and enjoys using the tool, what does that mean for Marc? Real-time information and accurate data—a lot of accurate data.  That's a much easier ship to steer.

@task is about delivering the ideal experience to each and every user so that they can get their job done effectively. We tailor each feature, each page, each interaction to the context and goals of the user. For example, Chris wants simplicity. He appreciates an experience that reminds him that he is a key contributor to the success of the organization. Giving Chris (and his peers) an engaging solution, tailored to his goals and context, increases the information flow that Marc needs to steer the ship.

@task focuses on delivering a streamlined and rewarding experience for everyone, creating an ecosystem of information that drives visibility, productivity and success.

Now that you've met Chris and Marc, let's talk about Jen...in my next post.

Simply put, Work Management is doing whatever it takes to get the right stuff done right. Let's break it down...


What is work?

Is it project based work? How about strategic initiatives? Processes? To-dos? The answer is yes -- and more. Anything you do that expends effort is work. Think about this for a minute. If you could draw a circle around "all work", what would that include?


What is management?

This is how you deal with constraints to achieve goals. Management includes elements like how you interact with people, the way you plan and use your time, what you do with money, etc. All of these can be barriers or boons in the process of reaching your goals.


Why Work Management?

Every organization struggles with similar objectives such as reducing waste, optimizing output, and maximizing value. To achieve these goals, we implement approaches like project management, or tools like PPM software. But do these approaches capture all work for all people? What about all of the pre-project effort expended developing ideas for strategic initiatives? What about all of the time spent on routine non-project processes and procedures? What about all of the conversations, interactions, and sticky notes that represent reality?

Work management focuses on helping you get work done -- whatever that work is. It is not confined to tickets, projects, or portfolios. Whether you have a project to manage, a list of to-dos, a process to monitor, or strategic objectives to push -- it's all work, and it needs to be managed to reduce waste, optimize output, and maximize value.

@task is work management software. Bring your work to @task, and we'll help you manage it. Our goal is to bring all people, all work, all together. How do we do that? Watch for my next blog post.