AtTask

A Toast. "To our new guests: The Business"

Those of us who have worked with Business Project Management Software have sampled from its vineyard of features. Over time, we acquired a taste for what we like, learned to avoid those we don't, and ultimately settled in on our favorites.

As PPM Software has matured, The Business has come to appreciate how they too can enjoy these Project Management Tools. As Project Management professionals, wouldn't it be decadent if we had time to play the role of  connoisseur, sharing the subtleties of our experience as we tour The Business around?

Well, sober up. There's never that much time.

That said, may I offer to at least fill your cup with one popular Project Management concept I've uncorked?

From Sippage to Slippage

Let's switch from Wine Country to Oil Country. On Oil and Gas projects, somewhere in the middle of the Project Plan, there's a Task where the well itself gets drilled; what's called the Spud Date. It's a key event in the entire project, and since lots can go wrong either side of it, The Business often watches the Spud Date to quickly gauge how the Project is going, typically in a Gaant Chart view.

If all Tasks are ASAP, a Project's Start date determines where the Spud Well (S) will occur. This is typically what it looks like in the future, while we're planning ahead, with no Tasks started yet (0%).
As time moves on, real work occurs and some Tasks get completed (100%). However, until a Task is marked as totally complete, @task pushes everything that's ASAP past it further into the future, assuming that the earliest you would mark it as complete is "Today". The dotted yellow bar shows what's CAUSING the delay, and the other shading shows the EFFECT of the delay.
If you realize you forgot to enter an end date, you can backdate a Task with the real actual end date (A). When you do, @task "snaps" the schedule back to that date, but then assumes (again) that any late Tasks can't finish any sooner than "Today".
Since it’s the Actual Tasks, the fact that is "Today", and the ASAP relationships that drive where the Spud Well occurs (S), there is NO POINT in adjusting the Start Date of the Project -- it would simply make the overall Project start earlier, without moving (S).

Last Call

I hope you can use this analogy to understand or explain why ASAP Gaant Charts move the way they do once a Project gets underway.

You are also welcome to download the original Excel version. It includes a similar example for a Project with a Start No Earlier Than restriction. For Oil and Gas, that is often the case when waiting for ground to freeze before the drilling rig can get into position.

For a Winery....hmm...please leave a comment with your own analogy.

I was reading "The Execution Trap" by Roger Martin

He cites a commonly used misleading phrase, "A mediocre strategy well executed is better than a great strategy poorly executed" If a strategy delivers poor results, how are we to say it was brilliant? Roger goes on to explain how the idea that strategy and execution are somehow two separate ideas is deeply flawed.

Traditionally, strategy is the purview of senior managers and consultants who then hand it off to the rest of the organization for execution. Strategy is choosing, execution is doing. 

Examples of front-line individuals developing ideas and procedures outside of a strategic role are many. All too often, organizations are not able to benefit from those developments due to preconceived notions about who are the thinkers and who are the doers.

Roger's point is that if there is no line above which strategy happens, then why make a distinction?

How are we to avoid falling into the same trap? I would suggest a couple of ways:

1. Open lines of communication. Some managers jealously guard their resources. They want to make sure that everyone plays by rules in the interest of 'efficiency' or in the interest of 'focusing on getting the job done'. Efficiency and accomplishment are good. However, organizations start to go sideways when people who want to share ideas are not allowed to. A good approach is to foster idea sharing and communication. Hold brainstorming sessions and invite all who care. 

2. Strategy is Action. Remember that strategy is action and that results are inextricably tied to that action. When implementing a strategy, you will never be able to hand off the plan to someone else to get those results. Consultants are a slippery bunch sometimes. They show up with intellectually solid plans, but seem to end their engagements with enough lead time to have a good excuse if the results don't come in.

I've lately been reading Zen and the Art of Motorcycle Maintenance, so I hope you'll forgive me for being a little philosophical. As Robert Pirsig talks about technology and quality within his narrative, I can't help but relate it to how we approach work. "The place to improve the world is first in ones own heart and head and hands," writes Pirsig, "and then work outward from there."

It's easy to put our faith in the system, the technology, or the process—but ultimately, it's the individual and how he or she relates to the work that produces what Pirsig describes as quality. "Real Quality isn't something you lay on top of subjects and objects like tinsel on a Christmas tree," argues Pirsig. "Real Quality must be the source of the subjects and objects, the cone from which the tree must start."

As project leaders, creating an atmosphere where the workforce feels more like they are part of the work (the Taoist calls it wei wu wei, or doing not doing) is critical for any real improvements in how we get work done. "Doing not doing" is like a ballerina that is no longer doing the dance—she becomes the dance.

In the early days of Tiger Woods' career, he was a great example of this. He practiced and practiced to the point that whenever he hit the golf ball, he didn't need to think about it anymore—he just stepped up and hit the ball ... perfectly ... as if the golf ball hit itself. A number of professional athletes sometimes reach this same level of awareness in their individual disciplines. They don't think about what they are doing, they just do it—or it becomes so second nature that they don't need to do it anymore, it just happens.

Is the ability to do this an aptitude? Is it something that can be learned—or even selected? I think it is all of the above. Creating an atmosphere where this can take place allows those project team members who might come by this awareness naturally to thrive, but there may be others on the team who just won't get it. There will be some of them that will be teachable and others that won't. The challenge for a project leader is weeding out those who don't or won't get it, and replacing them with those who can, or do. this is particularly important in organizations that empower their workforce with more autonomy and ownership. There may be some team members who just can't or won't respond, and will be slackers no matter what you do. They will need to be replaced with a workforce that understands and thrives in an environment like this.

"Is it hard?" asks Pirsig. "Not if you have the right attitudes. It's having the right attitudes that's hard."

Over the last year or so we've talked a lot on this blog about how empowering project teams with some autonomy and control over the work they do will help improve the project management process. With that being said, we should also talk about the need for individual project team members to step up and take responsibility for the additional autonomy.

As Uncle Owen said to Peter Parker in the Spiderman comics, "With great power comes great responsibility."

Over the last several months, I've talked to a number of project managers who have questioned the wisdom of giving individual project team members so much influence over the project management process. Although they have some valid concerns, I'm convinced that the real issue is less about whether or not team members should be empowered, and more about how we staff project teams and who we staff them with.

Over the years, I've had the opportunity to work with and manage some great people. Most were highly motivated and anxious to contribute. However, I have worked with others, who no matter what we did were never able to catch the vision of their role in the process. Unfortunately, as it became apparent that they were not able to contribute with an increased level of autonomy, their role on the team was eliminated.

The question then becomes, how do you choose the right team? Although there is no way to guarantee that you've picked the right project team, here are five traits that will help you build engaged, motivated, and responsible project teams:

1. Do they have the skills I need to make the project successful? Because I will be relying on them to do their jobs (so I can do mine), I always look for individuals who have demonstrated that they know what they are doing.
2. Do they have the ability to learn and stretch? I always look for people who aren't afraid to try new things, take on additional responsibility, and think "outside the box." I learned a long time ago that collaboration with people of different skills can be very productive.
3. Will they play and work well together? A superstar who is a jerk doesn't help the team. He or she might be highly skilled, or even the best at what they do, but if they don't get along with anyone I won't add them to my team.
4. Are they willing to take (and offer) constructive feedback? I don't call it criticism. Criticism doesn't help anyone, but feedback and honest critique can help a willing learner improve and increase their skills. That includes team leads and project managers. A willingness to incorporate constructive feedback allows everyone on the team individually, and the entire project team collectively to improve.
5. Can I count on them at crunch time? Every project seems to run into times when people need to put forth a little extra effort to make things happen. It seems like no matter how well you plan, there are always things that crop up to cause trouble. It's important that we can count on each other to pitch in with a little extra effort when this happens.

Building a project team where everyone shares these traits is easier said than done. However, I've found that it's critical to consistent project success and absolutely necessary for project teams that want to empower individuals to increase performance. How do you pick your project teams? How can you tell if you've got the right combination of skills?

Over the years I've read dozens of articles (and even written a few myself) about what it takes to plan and execute a successful project. However, over the years I've discovered that opinions are like belly-buttons, everybody has one and they're all different. Although there's no doubt in my mind that sound project management methodology includes a number of considerations like risk, reward, resource needs, and stakeholder buy-in, I'm convinced that the linchpin for project success is the end user and how he or she interacts with the project management process.

What's more, without end user buy-in and adoption, PPM software implementations fail. Period.

I believe there are a number of reasons this is true. Not the least of which is that the workforce has changed. In the 30 some years of my career, I have observed almost a generational change in attitude about how the workforce responds to management. Today's workforce doesn't seem to be motivated by a command-and-control management structure. They are looking for a bigger role in the process than "do what you're told."

Recognizing and appropriately responding to this reality empowers project managers because:

1. It engages project team members in the process making project management tools adoption easier
2. It allows those closest to the work (individual team members) to capture more accurate status and other project information
3. Team members with greater ownership in the process are more likely to meet deadlines and milestones than their less engaged contemporaries
4. It allows project managers to spend more time managing projects and project teams and less time managing spreadsheets and building reports

Of course linchpin doesn't necessarily mean "silver bullet." There will be some team members who just won't get it, and project managers will have to make some hard decisions about who is on the team and who isn't. That being said, project teams and project managers who are able to work together in this type of environment will enjoy an atmosphere of more meaningful collaboration, enhanced creativity, and greater project success.

What are you doing to create a more engaged workforce?

Ty Kiisel recently wrote about how we automatically do things that others don't necessarily know how to. His example came from spending time teaching friends how to fly fish. Like Ty, I also love fishing except I prefer the sea to the river. That might seem a bit weird for a girl, but I grew up in a city where about 1 in 3 households owns a boat and because my family has always been a part of that statistic I was hooked, so to speak, at a very early age. Now whenever I'm home I spend as much time as possible out on the boat with a fishing rod in one hand and the next piece of bait in the other.

But like most things, a great days fishing doesn't happen by waving ones magic wand in the air and keeping fingers crossed. Project teams can't perform at their best either with that as a baseline. The same principles that turn a fishing trip into a great day out go a long way towards developing a superb project team. I've narrowed them down and called them the 4 P's of People on Projects.

1. Preparation: PMs know all about preparing for a project. We have a map (project plan), directions (objectives), and supplies (tools, techniques, budget, team, etc...). All we have to do is get on with it, right? Ha, if only it were that simple! Projects and their success rely on people and any PM worth their hourly or daily rate will be equally thorough in their preparation at a human level as they are at everything else. They'll show leadership from the start to maximize the chances of success. This cascades through the team allowing them to prepare individually and jointly with clear boundaries and expectations. Forgetting the bait and running out of fuel is not a good start to the day!
2. Practice: I started with a sprat line off the wharf and soon moved on to a big-girl's fishing rod. It took practice and some help from my Dad to master the change. Like me, people on projects don't always get it right the first time. I'm an advocate for situational and experiential learning, so even if someones done it before they need to continue to focus, adjust something here or try something different there, to do better next time. Our job as PM is to give encouragement, guidance, and the opportunity for practice. If we don't how else will anyone improve?
3. Patience: With project deadlines getting tighter PMs need to hone their instincts. We must intuitively know when to bite our tongue and when to push back. Being patient early allows us to get to know people's natures and people, like fish, will tease to see how far they can get before being caught. Personally I like the 3 strikes and you're out approach, which in tandem with practice sets clear boundaries and behavioral expectations. If that fails try breathing 1, 2, 3...
4. Prize: My scrap of patience paid off this year with the best snapper I've caught for a long time. It weighted about 2.5kg (5lb), gave me a huge buzz and a full stomach. Every person on a project wants the big prize; to see their project Go Live, deliver against expectations and be labled by all as a resounding success. It makes good reading on CVs, helps with promotions or career prospects, gives people something to crow about and for contractors can lead to repeat business. If everyone does the other Ps well, the prize will be a no-brainer.

What's my ultimate fishing prize? To catch, tag and release a marlin. I think I'll need a bigger rod for that though...

About this time last year my Boston Terrier Cosmo passed away. He was, in my humble opinion, the best dog that ever lived. He was a gentle and loving companion who transcended his canine nature and became one of our family. It didn't matter if I had been gone for five minutes or a week, he was always glad to see me and truly exhibited unconditional love for me. As he got older he may have lost a step or two, but he was still willing to jump in the Jeep for ride, sit by my side on the couch, or chase a ball or stick thrown in the back yard.

You might be asking, what made Cosmo the "perfect" companion. And I would have to say, we understood each other. Although he didn't speak English and I didn't speak canine, we were able to effectively communicate. Cosmo taught me a lot about being a successful "accidental" project manager.

From the first few days he joined our family as a tiny "beanie-baby" puppy, throughout all of the 13+ years of his life, I made it a point to communicate clearly, concisely, and consistently with him—and he with me. My instructions were never ambiguous and his reaction to my instructions became consistent and predictable. (I wish I had known Cosmo when my children were small, I probably would have communicated with them in a more consistent and less erratic manner.)

Here are some of the management tips I learned from Cosmo:

1. People want to do a good job, they just need to know what a good job is: Cosmo's nature was to please me. He wanted to be a good dog, it was my job to teach him what being a good dog was. The people on project teams aren't much different. Most people want to do a good job. If you are clear up front as to what a good job is, most team members will work to do it. What's more, when it comes time for a review, they will know whether or not their performance has measured up or not—you won't need to tell them.
2. Hold people accountable to expectations: If Cosmo ever did something I didn't approve of, all it took was a look from me and he would straighten up. Once project team members know and understand what a good job is, it's important to regularly hold them accountable for their performance. Give them an opportunity to report on what they are doing and how they are meeting expectations. Accountability is not a bad thing. In fact, it's an important part of building effective teams. What's more, people crave ownership and accountability in the workplace.
3. Praise publicly and specifically: Cosmo loved hearing that he was a good dog. In fact, he actually seemed to like it when I praised him in front of someone else (however I could be imagining that). Most people like to be recognized for a job well done. That being said, insincere platitudes will fall flat. If you are going to recognize accomplishment, make sure and make it specific and sincere. "Great job Johnson," is not as meaningful as, "Johnson, all the work you did on that Acme project will really help us get their order. Great job."
4. All dogs are not Cosmo: I guess it doesn't really matter if it was because they were never taught properly in the beginning (or if they were just bad dogs), some dogs just don't respond the way Cosmo did. As you manage people, you will find that there are team members who just won't respond to this (or any other management approach) and will need to be let go. Just because they are available doesn't make them right for the project team. I don't let just any dog come into my house and sit on my couch with me.

Of course, there is a difference between people and animals...isn't there? However, regardless of the way you manage projects or your project management software, we can learn a few things from the best dog that ever lived. I have found that incorporating this people management approach into my work management methodology very successful when working with teams responsible for creative problem solving—you might too.

Do you have anything to add to the list?

ShareThis

As a teenager, I was a lifeguard and swimming instructor at my high school swimming pool. I spent the summer teaching two- and three-year-olds to swim. Over the three or four years I taught swimming lessons, I noticed that there were some traits that successful swimmers had in common:

1. They overcame their initial fear of the water
2. They could hold onto the side of the pool and kick
3. They weren't afraid to get their face wet and could blow bubbles under water
4. They had fun splashing and playing in shallow water

As a swimming instructor, if I could help my students foster these behaviors, it wasn't long before they were jumping off of the diving board and swimming to the wall of the pool. If I could work with them all summer long, I could help a non-swimming three-year-old progress from blowing bubbles to swimming laps.

Successfully managing projects isn't really that different. I've noticed that most successful project managers are able to:

1. Make sure the project has a strong sponsor.  Every project needs a sponsor who will evangelize the value of the initiative throughout the life of the project.
2. Make sure the project is adequately funded.  The temptation is to take whatever funding is offered, but without adequate funding—it's usually the project manager who ends up in hot water when the project fails for lack of financial resources.
3. Pick the right team.  Make sure the team includes all the skills that will be needed for success.  Just because someone is available, doesn't always mean they are the best to work on your project.
4. Plan.  Planning is more than just preparing to deliver the final product.  It should involve a continual process of evaluation and adjustment.
5. Know the end before you begin.  Make sure you know what the outcome of a successful project is before you start.  What does "done" mean?  Financial experts call this an "exit plan."
6. Prepare for change.  The very nature of projects create change.  Whether it's a new product or an improvement in process or technology.  Makes sure to prepare for the change.

Regardless of the particular work management methodology you choose, or even the project management software you use, if you are able to encourage some basic project management behaviors that have proven to produce successful projects, I can't promise that you'll be able to swim laps, but you'll likely become skilled at leading successful project teams.

Are there any other basic practices we should add to the list?

Many organizations want to go straight from spreadsheets to PPM without ever understanding the fundamental principles that govern project portfolio management.   May I suggest five underlying assumptions that must be in place for organizations to fully adapt the PPM methodology? *

Five Underlying Assumptions of PPM:

1. Employees have a basic understanding of project management principles
2. The staff has a desire to select projects based on a structured system
3. The organization has a process for evaluating project performance based on specific goals and commitments
4. A team is created for portfolio governance
5. The organization has project management tools that support PPM functions

First, for an organization to effectively implement PPM it must have a staff that is capable of managing and supporting the process. This is often accomplished through the creation of a centralized project management office or PMO.  The PMO consists of professional employees that understand the basic principles of project management and have the required knowledge and capabilities to create and manage a system for project standardization and consistency.

Second, once a PMO has been created, or a similar department or group, the PMO must have a desire to develop a structured approach to selecting projects.  This approach should be based on a fair and balanced ranking system, one that selects projects based on a clear set of criteria and objectives.  The projects selected should be aligned with business strategies and placed in portfolios that represent the tactical implementations of such strategies.
 
Third, after projects have been selected for the portfolio, they must be managed using a process that evaluates project performance based on specific goals and commitments.   The PMO must be able to assess the ability of the project to continue to meet the original selection criteria.  Projects that fail to provide adequate value or are inefficiently using resources must be delayed or terminated based on the established culture and practices of the PMO.

Fourth, in addition to the creation of a PMO or project group, new roles will need to be created to govern PPM and monitor the performance of the project portfolios.  This team will be able to act for senior executives (or may include the executives) to oversee the portfolios.

Fifth, the PMO should review its current project management tools for support of the new PPM functions.  If the existing software does not support PPM or doesn’t provide the functionality needed, the PMO should evaluate alternatives and choose a set of tools that best fits the organization’s goals and processes.

In conclusion, if an organization is seriously considering a move to PPM or is looking to improve its PPM processes, it must build a foundation that adheres to the underlying assumptions of project portfolio management.

A good caddie is critical to a successful tournament for a golfer.  On the golf course, a caddie has a number of basic responsibilities:

• Ensure that the proper number of clubs are in the bag
• Help in the selection of clubs for specific shots
• Let the golfer know where pin placements are for each hole on the golf course
• Alert the golfer to where a good spot to hit their shots would be, and if they miss, where to miss
• Help read putts if needed

A great caddie will have walked the course and knows everything there is to know about the softness of the turf, the condition of the sand traps, and has personally paced off the yardage for each hole.  This information allows the caddie to provide the information the golfer will need to play the best round of golf possible.

Throughout the course of a project, it's often the tough decisions made by stakeholders that make the difference between a successful project and one that fails.  Sometimes the importance of stakeholders in the success of project based work is overlooked.  However, it's vital to keep them informed with the most timely and reliable information possible.  Regardless of  the project management software you employ or your particular work management methodology, here are three keys I've discovered to encourage successful stakeholder involvement:

1. Ensure that stakeholders, sponsors, change agents, and champions, are involved and in agreement throughout the project.
2. Guide the decision-makers through the key steps to success and make sure they are applied consistently throughout the project.
3. Keep stakeholder's decision-making efforts based on the best practice areas that have helped other projects deliver successfully to achieve the desired results.

Not unlike the relationship between a professional golfer and caddie, the biggest benefit to keeping stakeholders in the loop is an increase in stakeholder collaboration and a more successfully portfolio of projects.

How do you keep stakeholders engaged in your projects?  Do you have any suggestions that I may have left out?

Learning project management best practice doesn't just happen. Especially for those who don't come from the traditional IT project portfolio management background.

Over the last couple of years I have noticed that there is a lot of project-based work accomplished by managers who aren't formally trained project managers as companies turn to projects for increasing productivity. Because these "accidental" project managers are often left to themselves to figure out the best ways to manage projects, motivate teams, and get work done, searching out information to help learn best practices becomes critically important. That being said, some of those "accidental" project managers turn out to be incredibly effective and some of the most intuitive and successful managers.

Without getting into a discussion about certification and formal training, there are other ways for budding project managers to learn the ropes. (Anyone considering the path of the PMP should talk to Josh Nankivel at PM Student or Derek Huether at HueCubed, both of these guys are great resources for preparing for the PMP exam.) I'd like to talk about some less formal ways we share information and learn best practices.

Anyone who has read this blog for any length of time knows that I am a big supporter of the social network of project managers on Twitter who so willingly share valuable information with the rest of us. There is a tremendous amount of really good, real-world information, available to anyone who is willing to do a little bit of digging. There are excellent blogs, webinars, user groups, conferences, tradeshows, and seminars. In fact, it's never been easier to learn how to best implement sound work management methodologies within your organizations.

I think this almost instantaneously available information benefits the project management community. We are very fortunate as project professionals that there are so many talented and capable people willing to share their insight into what makes successful projects click and what it takes to be a skilled project leader. I believe this "community" lifts the profession and creates greater perceived value in the workplace.

I know that I enjoy the time I spend with my peers in person, on the phone, and even online. I think it helps me be better at what I do and inspires me to share with the rest of the community. As I talk to people about what makes them successful, it's rarely a discussion about software (although the right software tools contribute to project success). It's usually about implementing sound methodology and best practices.

Why don't you give it shot. Ask a question via someones blog or on Twitter and see how willing they are to help you find an answer. You might be surprised at how quickly someone who normally charges hundreds of dollars and hour in consulting fees will step up to answer your question.

Change is hard. We humans are creatures of habit and we don't like it when someone upsets the apple cart. That being said, projects often react like living, changing creatures. Sometimes it only takes a few hours for a successful project to morph into something spiraling down the vortex to disaster. With that in mind, project management might sound like a counter instinctual career choice, but I tend to look at it the same way some cultures look at their dream-lives. By overcoming their fears in their dreams, it makes them stronger in their waking lives. Change might be hard for us to face, but the more often we face our fear (of change), the better we get at adapting and overcoming.

Because projects change, knowing (and then educating everyone involved with the change) what to expect can make changes a little easier to deal with. When the change involves something more than minor project changes, the "fear of change" in most cases is simply a fear of the unknown. Here are some of the most common fears that organizations face as they try to change or implement new project management methodologies:

1. It's Different: Realizing that there are some people who thrive on change, but most people don't, is important. You may get some push-back simply because it's a change.
2. Some Managers are Uncomfortable with Additional Scrutiny: Projects that might be important to one senior manager may not be as important to others. This could make some managers a little nervous that their projects might not stand up to peer review.
3. Some Projects are More Important than Others: Implementing a sound work management methodology will mean that only those projects that provided the most value will get pushed forward—not the "pet" projects of influential stakeholders. Because this might negatively impact some projects, those stakeholders may try to block the process.
4. There are Tough Decisions to be Made: Best practice requires that some projects will get funded and others will not. It's important that senior managers understand that they have a responsibility to the organization—not just their individual departments. There will be managers who don't like this fact.
5. Implementation Takes Time: Implementing a new methodology for project-based work takes time. Because it doesn't happen overnight, there will be those who will say they don't have time for this, but it's necessary to take the time to be successful.

Like any organizational culture change, there will be those who embrace the change and others who don't. Be prepared for both, and your efforts will be a success. What are some of the challenges you have successfully faced when implementing a major change like a new project management methodology?

Why Beyond Spreadsheets?

For almost 4 years I have traveled the world meeting with companies of all sizes, from small- and medium-sized companies, to Fortune 500 companies.  These meetings consist of understanding business needs in regards to managing projects, work, and resources (people).

The One Question and the One Answer

The one question I ask during each meeting is this, "How are you currently managing your projects, work, and resources?"  Surprisingly the majority of the responses are, "We use various types of spreadsheets."

These spreadsheets range from small to complex and include:

• Macros
• Access levels
• Templates
• Business processes

After talking with companies for only a few minutes, we eventually discuss what they call Spreadsheet Pain, which is defined as "when spreadsheets fail to scale".  The pain they describe includes hours spent manually updating, gathering, and compiling data that executives and managers can use to make informed business decisions.  Not to mention, the pain caused when someone updates or reports status on outdated information.

Once we are done discussing "Spreadsheet Pain" we turn our discussion to the world beyond spreadsheets, which has been accelerated with all the technology advances and the ever-pressing need to be more efficient with company resources.

Beyond Spreadsheets

My blog will discuss best practices, methodologies, and products beyond spreadsheets that help companies focus on managing projects, work, and resources at the optimal level with world-class efficiency.  I am not totally ruling out spreadsheets, because spreadsheets are the basic foundation needed to excel in the world beyond spreadsheets.

5 Major Benefits from the Getting Beyond Spreadsheets

1.  Centralized data in one location to manage and report on all you company's projects, work, and resources
2.  Huge productivity gains when the transition is made from manual processes that take hours to stream-lined processes that take seconds
3.  Real-time visibility into your projects and work that provide an accurate understanding of status and needs, enhancing accurate decision-making on complete information
4.  Maximized resources that occur when every person in your company is aligned and focused on the work that will accelerate the attainment of strategic and financial goals
5.  World-class efficiency that accelerates market penetration, making your company a competitive force and a leader in your industry

These are just five of the many benefits I have witnessed companies experience when they make the tranistion from complex spreadsheets to the world beyond spreadsheets.

Managing stakeholder expectations is an important part of managing project-based work. If you're lucky, project stakeholders have clearly defined the value of what the successful outcome of their project might look like. I say lucky because unfortunately, clearly defining the potential value of an initiative before the project has begun seems to be the exception rather than the rule in most organizations. However, if success is not clearly defined, it's up to the project manager to initiate a dialog to determine the value and desired outcome. Otherwise it's difficult to successfully complete any project. And what's more, it's never a good idea to be measured against a moving target.

In most organizations, a stakeholders attention span is pretty short. Long projects that require a lot of stakeholder patience tend to falter and ultimately fail. Providing value regularly, at short (3-4 week) intervals, keeps stakeholders engaged and interested.

It's sometimes easy for change orders to morph a project into something different than what was intended. Keeping stakeholders focused on the objective can be challenging, but it's critical for project success. If a change doesn't contribute to the defined objective, stakeholders need to understand the ramifications and how changes could impact the final outcome.

When reporting to stakeholders, it's important to remember that executives aren't as interested in your particular work management methodology as they are in results. Keep stakeholder communication focused on progress and value. Be concise and brief. Sending a lot of time buried in the details with stakeholders will not only be frustrating for them—it doesn't do you any good either.

Four keys to managing stakeholder expectations:

1. Make sure "project success" is clearly defined before the project begins
2. Don't make stakeholders wait too long before they start to see value
3. Execute against the objective to ensure project success
4. Keep it simple when communicating with project stakeholders

Although none of these suggestions require project management software, they will keep stakeholders informed and happy. I'd welcome hearing what some of you are doing to manage stakeholder relationships.

I'd like to talk about the Nintendo Wii.

Earlier in the month I wrote about how approaching software design from the perspective of an anthropologist was a good idea in Project Management Software Development: A Fresh Look From a New Perspective. I'd like to continue that discussion by talking about how we, as software users, sometimes struggle with what we really need vs. what we think we need—and how software designers need to somehow figure out the best way for us to interact with the software. (I think this applies whether or not we are talking specifically about project management software. As an industry, PPM software just happens to be a really good example of a failed development process.) As I describe in the previous post, human behaviors are pretty complicated things to measure. There are so many variables associated with how we react to different situations that it's difficult to quantify our behaviors in a way that can be illustrated in a graph or spreadsheet.

Love it or hate it, the way my Nintendo Wii was designed is a good case in point. Genyo Takeda*, the general managers of Nintendo's integrated research division, said the following about the possible consequences of allowing convention thoughts about video game design to control the development of the Wii:

500 annual projects sounds like a lot of work.

In a recent conversation I had with a project manager for the marketing department of a leading online and offline retail chain, I was told that she and her staff of 10 project managers handled 500+ marketing projects per year. Even with the understanding that marketing projects are often of shorter duration than a large IT project, I was still impressed (that averages to two new projects each week). Not all marketing projects are of short duration, and many rival the complexity of a large IT project.

As we discussed what they were doing to manage projects, their goals for improving the way they approached project-based work were very similar to how a traditional IT organization might look at work management. This conversation validated in my mind the notion that there are many organizations turning to traditional IT project management processes to improve efficiency and get more work done regardless of they type of work they do.

I don't think this comes as a surprise to anyone. I think most of us in the project management industry have recognized that PPM isn't just for IT anymore. However, at the end of our conversation she made a couple of observations that I think are very relevant for software providers:

1. They spent four years looking for the right solution for their marketing department.
2. It was difficult to find a solution that spoke to the needs of creative departments.
3. They would like to see something that would be more conducive to an audience of creative thinkers. Something that was more visual, included a more creative color pallet, and was simple to use and more straightforward in approach.

I've heard these same suggestions from IT project professionals, but as project management methodologies expand outside of IT I think it becomes even more important to approach the project management process from the perspective of the user. This is something I find myself talking about on a pretty regular basis because I believe the end user is the linchpin to project management software adoption and success. I most recently talked about this in a post titled, Overcoming the Knowledge Worker Assembly Line.

When Companies Merge

Synergies...Efficiencies...Economies of scale....that all sounds great! Why wouldn't two big companies want to merge?

Well, one reason might be that if they're in the same industry, they probably use a lot of the same software, and sorting out which packages to Retain and what to Decommission is an enormous undertaking.

It's a good thing that one of my clients knew about AtTask when they needed to sort it all out.

The AppRat Team

Our Applications Rationalization Team (or AppRat, as it's more commonly referred to) was charged with sifting through 4000+ software applications as two major companies merged. Initially, we tried to use a combination of a small website database and spreadsheets stored in Livelink to keep track of things. It didn't work, as this diagram shows, so we converted to @task.

Before: Web DB/Livelink/Excel - Limited access to Web DB - Restricted to 99 custom columns - Daily extract to Livelink - Repetitive data reformatting - Data staleness caused confusion

After: @task - Multi user environment - Unlimited custom parameters - Common view to all users - Reusable custom reporting - Real time reporting for all audiences

Ownership vs Usage

The AppRat team set up a single Project with a Task for each of the 4000+ apps they needed to either Retain or Decommission. Behind each such app Task, they also tracked over 100 custom data parameters to help guide the Work Management. Often, apps were used by more than just one department. And sometimes, the Owner making the Decision to Decommission an app wasn't the same as the User(s) wanting to Retain it.

Hence the bomb scare that lead to this post.

Always cut the Red Wire

With all that data flying around, it's easy to see how certain scenarios could be overlooked. Recently, our executives challenged us to prove that we were only Retaining what was Used, and that we were Using what we Retained. Huh. Sounds obvious...but we really weren't sure how to show it. So we decided to build a dashboard to look for exceptions.

It worked. We can now spot and defuse explosive exceptions right away. There's a screen shot below with a real example.

The moral, though, is that by leveraging @task's flexible custom data and exceptional custom reporting, we used our IT Project Portfolio Management platform to solve one of the more challenging aspects of the merger.

That's dynamite.