As I’ve talked to customers, I’ve met dozens of people who, like me, are responsible for getting stuff done but don’t fit the traditional IT-specific project management model.  They do project based work, but that’s where the similarity ends.

Why does it matter?

Let me give you an example.  One of our customers was looking for a solution to help them manage a fairly repeatable manufacturing process.  While looking for a software solution, they found a number of products that were designed around the software development cycle.  (Project management is a more mature discipline within the software industry than it is in other disciplines throughout the enterprise.)  This executive was looking for something that would be more adaptable to a manufacturing process and usable for a non-technical workforce.  They found that most of the products they looked at weren’t flexible enough to adapt to their process and were too cumbersome for their workforce to use.

While discussing this with my colleague in product management, he pulled down the PMBOK (Project Management Book of Knowledge) and suggested that there was a lot of really good information in traditional project management methodologies that shouldn’t be ignored just because a manufacturing or marketing company doesn’t manage the same type of process.  I agree.  That being said, project management software should streamline and simplify, rather than complicate the work management process.

As we’ve talked before, I believe that a project manager’s role within the organization is to facilitate an efficient process, assist the workforce in overcoming impediments to productivity, and keep projects on time and on budget.  However, most project managers I’ve met spend the majority of their time manually collecting status from project team members, compiling and analyzing raw data, and preparing reports that are eventually pushed up to the executive suite.

It requires a skilled professional to do the former, technology can automate the latter.

Does your project management software enable you to help your project teams be more efficient?  Or do you spend the lion’s share of your time with your nose in a spreadsheet compiling status reports for the boss?

Project management expert and author Harvey Levine talks about making reports and dashboards a more effective tool for your organization.  Click HERE to read his white paper titled, “The Dashboard Blues.”

The earliest signs that a project is in trouble are hard to measure objectively, but are relatively easy to spot if your watching:

1. Lack of interest—Whether it is a lack of interest within the project team or project stakeholders, it’s often demonstrated by people not showing up for meetings, a lack of active participation and feedback, or a poorly energized user base.  These are warning signs that a project is in trouble.
2. Poor communication—If nobody is communicating, including stakeholders, team members and end users, there could be a problem.
3. Lack of velocity—Projects always need to be moving forward.  The best way to keep a good velocity is to divide your project into a lot of small deliverables at frequent intervals.  If the project isn’t moving forward, it’s likely in trouble.
4. A “no-bad-news” environment—Nobody likes to be the bearer of bad news.  But sometimes organizations need to face the reality of negative news.  This includes project team members who don’t want to be the messenger and business leaders who tend to shoot the messenger.  If there is not an environment where the communication is honest about “reality,” projects tend to fail.

Intangibles aren’t the only indicators that a project is in trouble.  There are a number of concrete signs you can watch for too:

1. Lots of overtime—A project running on schedule should have little or no overtime.  Overtime is often a quick fix, but leads to poor employee health resulting from too much caffeine, too many late nights, and too much junk food.  (It also leads to mistakes.)
2. Diversion of resources—When people are pulled from one project to work on something else it could be a sign of trouble.  If you’ve budgeted your human resources properly, a few hours here and there on a troubled project can quickly add up and cascade down, endangering healthy projects.
3. Ratios trouble—Cost ratios and schedule ratios are financial metrics that allow business leaders to measure budgeted time and money verses money and time actually spent.  Without metrics, all you have to rely on is the accuracy of the communication you receive from project teams.
4. Milestones aren’t met—This is pretty obvious, but it is surprising how many times this warning sign is ignored.  Small, discrete, and often, are the guidelines for the milestones of a successful project.
5. Scope Changes—A common approach to shoring up a lagging project is to change the scope.  Eliminating features or relaxing requirements is not uncommon, but if project teams are doing it because the project is in trouble, it’s a huge warning sign of a failing project.

Of course, warning signs are not the harbinger of doom, they are just warning signs that a project might be in trouble.  Depending on your work management approach, the right project management tools can help your organization identify potential issues early, when there’s still time to do something about them.  These challenges are universal to anyone doing project based work.

What is your experience?  How do you spot a struggling project early and take action to remedy the situation?

Click HERE to read more about how to spot a failing project.

Recently, I got a wild hair and decided I wanted to build a boat.  I’ve searched the Internet for the last several weeks looking for the right “project.”  I found a builder in Maine who’s website convinced me that I wanted to buy the plans to build one of his boats.  I measured my garage to see how much space I had to work with and narrowed my choice down to two styles.

Late last night I wrote him, explained my level of experience, and asked him if he had any advice.  His reply came early this morning.  He described the characteristics of each boat, including building and sailing, and asked me questions about what I wanted to accomplish with my boat.  What was I looking for in the building process as well as what I wanted in sailing the boat later?

Basically, he presented the business case for each boat including:

1. My goal for building and sailing
2. The unique characteristics of each boat
3. The costs associated with building each boat

Business leaders today often face the challenge of too many good ideas and not enough resources to act on them all.  Sometimes difficult choices need to be made by organizations doing project based work.  Work management tools should facilitate the evaluation of potential projects to help make those decisions based upon something more than whether or not a project is a good project.  In today’s economy the decision must be based upon whether or not the project is the best project, or will provide the most value. And doing that requires decisions based upon predetermined metrics that include:

1. Alignment to strategy and vision
2. An understanding of the potential risks along with any risk mitigation plans
3. The rewards of the potential project
4. The costs, including the opportunity cost of not doing a project
5. The resource requirements

How does your organization evaluate potential projects for execution?  Does your project management software help facilitate those decisions?

By the way, I’ve made my decision and will be purchasing the plans for my boat project tonight.

This is particularly important for organizations doing project based work.  Why?  Because those organizations can validate and measure whether or not the initiatives they are working on align with business and financial objectives.  If they do, the odds of the business being successful increase—if not, the odds of the business surviving long term are slim.

Of course, depending on your organization, validating that the work being done aligns with business and financial goals is easier said than done.  Particularly if your organization doesn’t naturally think strategically (which some don’t).  However, in today’s economy it’s critical.

The right work management software can certainly help.  The right project management tools allow executives to see down into what’s being  done by the workforce and confirm that it aligns with their strategy and vision; and what’s more, the workforce can see and understand just what the vision is.

Here’s a good case in point. Back in the 60s, when the Kennedy administration was committed to putting the first man on the moon, the story goes that there were rumors of problems at NASA and that the people there weren’t dedicated to the administration’s vision.  So President Kennedy hopped on Air Force One and headed to NASA for a personal visit.  He wanted to reinforce his commitment.  Before the meeting, he stopped into the restroom where a janitor was emptying the trash and puttering around.

The President asked, “How are you?”

The janitor replied, “I’m doing great. I’m putting a man on the moon.”

The President left the restroom, got back on Air Force One, and flew home to Washington.  There was NO problem at NASA.

Making the strategy and vision accessible to everyone helped NASA put men on the moon.  I can still remember looking up at the moon the night Neil Armstrong made “One small step for man, one giant leap for mankind.”

I’m glad that janitor knew what he was doing.

What does your organization do to make its vision accessible to everyone?

If you would like to read about what Buckman Labs does to ensure that everyone knows the strategic value of everything they’re working on, click HERE.

That might sound overly simplistic, but in light of what we talked about yesterday, I thought it was relevant.  They had an accurate understanding of their current situation and were able to articulate where they wanted to go.  They are not a typical IT project management software user, they manufacture fixtures and displays for retail stores, however they do project based work.  They needed a solution that would enable them to implement their manual work management process into a business project management software.

If the first step to a successful project management software implementation is to have a clear understanding of where you are, the second step is the ability to identify and articulate where you want to go and what you want to accomplish.

To what do you attribute your success?

The C-suite points at their PMO and project managers.  They in turn point at individual project team members and right back up to the C-suite. Everyone points at their project management software.  Who do we blame for the abysmal project success rate? (The Standish Group’s 2009 Chaos Survey indicates that 66% of IT projects fail.)

I think there’s more than enough blame to go around.

As we’ve talked about recently, the IT project failure rate is a reflection of a problem that encompasses the entire process.  It all starts with project selection.  If organizations don’t have a formalized process for evaluating potential projects, it’s easy for executives to make knee-jerk decisions based upon the wheel that squeaks the loudest or the personal preferences of a powerful stakeholder.  Either way, that might not be the best way to make decisions that commit a company’s resources and manpower—and certainly isn’t a strategic approach to work management.

I  read a report last week that suggests that CIOs blame their PMOs for the horrible project success rate.  As I read the report I thought, what else is the CIO going to say?  Let’s look at this logically.  Sure, an immature PMO could have something to do with poor IT project management, but what are the odds that nearly every PMO is incompetent?  Pretty slim in my opinion. That being said, I think there is a problem with typical project management methodology.  Managers spend way too much time collecting data and building reports.  And those functions do nothing to help encourage project success.  Project managers should be in the trenches, helping teams be more productive.  If there is a failure in the PMO, it’s in their inability to foster a hands-on project management approach.

Project status reporting should be an automated function.  Regardless of your project management solution, if it requires managers to manually build reports to push up to the executive level, the software isn’t doing its job—and is where traditional project management software fails.

Most project portfolio management (PPM) software addresses the business intelligence needs of executives and ignores project teams, which is where the rubber hits the road.  The fact that most PPM software is difficult for the end user to use means that they won’t.  By ignoring the end user, most project management solutions guarantee that the data business leaders have to work with with be inaccurate and out of date.  What’s more, if they force project managers to manually collect project data and spend the lion’s share of their time creating reports, managers are merely reporting on projects instead of managing them for success.

In my opinion, the key to successful project management is three-fold:

1. Make it easy for project teams to contribute to the process.  Don’t force them into a maze of complicated procedures to update status and get their work done.
2. Automate status reporting so project managers can manage projects, rather than merely reporting on them.
3. Give business leaders the tools to evaluate potential projects to determine which provide the greatest business value and contribute to the strategic vision of the organization.

Who’s to blame for the astounding failure rate of IT projects?  We all are.

What do you think?

Click HERE to read about what Trilliant’s CIO Tom Hines did to maximize departmental effectiveness.

I propose this is a systemic problem that will require a systemic solution.  Many companies are surprised to discover that an approach that addresses the tactical needs of the workforce and the business intelligence needs of executives, empowers organizations to focus on profits and successfully manage projects.

It’s about doing the right projects, not just doing projects right.  Before any project under consideration begins, there are a few very important questions that need to be asked:

1. What are the high-level objectives of the project?
2. What are the estimated costs—and the anticipated rewards?
3. Does it align with the mission, vision, and values of the organization?
4. What are the risks assocaited with pursuing the project under consideration?

In a perfect world, every potential project that provided buisness value would be pushed forward—however, we all know that there aren’t always enough resources to accomplish everything—and decision makers are often forced to choose which worthy projects will go forward and which will be left behind.

Projects struggle when the work being done by teams doesn’t align with the strategic vision of their organizations.  Bridging the gap of strategy and execution requires project management tools that address the busisness intelligence needs of executives, the process management needs of managers, and facilitates the capture of accurate and timely data from the workforce.  In my opinion, any solution that doesn’t provide this kind of work management functionality will ultimately fall short.

What do you think?  Do you see a disconnect between strategy and execution in your organization?

Click HERE to read the free whitepaper Project Prioritization and Implementation: Bridging Corporate Strategy and Project Execution.

Jason Erdahl, Executive Director of Digital for the Star Tribune describes what AtTask is doing for them.  “AtTask is a great fit for the Star Tribune.  It allows us to manage workflow in one of the most important things we do: making our customers deliriously happy.  The way it does that is so focused on our business needs that I cannot imagine having the same process without AtTask.”

Other Q3 highlights include:

• Jumping from #420 to #178 on Inc. magazines Inc. 500 with three-year sales growth of 1,097%
• Being named a “leader” for our SaaS/On-Demand PPM solution in an IDC MarketScape1 report issued in August
• The AtTask July Update that provides additional functionality to help organizations propagate their use of @task throughout the enterprise

Click HERE to read the entire press release.

IT Executives are Looking at Project Success Differently

Although they still see keeping projects on time and on budget as a priority, those criteria are also being measured alongside better meeting the requirements.  Pushing a project to complete on time is not the whole objective, ultimately the project needs to deliver the desired result as well.  Along with keeping projects on track, most organizations are understanding:

1.  It’s about doing the right projects, not just doing them right—Delivering business value and satisfying customers is becoming more important than ever—and it starts with the evaluation of which potential projects will meet those needs and provide that value in the first place.  Hopefully this has always been important, but organizations are realizing that they have to do more than give lip service to meeting customer expectations while meeting organizational goals.  It must become a primary measurement of how we determine the success or failure of any project based work.
2. Project teams need to completely understand business needs and deliver software that meets those needs—Although everyone would agree that “quality” is very subjective, if everyone on the team doesn’t have a thorough understanding of the costs of defects and rework, it doesn’t matter what work management tool you use, it won’t help.  Edward Deming used to talk about how organizations must build quality into the product, it can’t be inspected in.  Quality assurance needs to be a part of every process from the very beginning.  Smart organizations are looking at defects and their root causes throughout the project life-cycle to develop methodologies that improve the quality of their final deliverables.
3. The final product needs to be stable, compatible, and easily maintainable—It is just too expensive for organizations to maintain software that is incompatible with current systems or unreliable.  Because staff and maintenance budgets are at a premium, software that isn’t will be abandoned for something that is.

What are you seeing in your IT organization?

PPM author and expert Harvey Levine talks about bringing your organization to “the desired future state,” and why it’s important to work on the right projects as well as doing them right.  Click HERE to see the brief video.

It’s easy for vendors and the buyers of project management software to get derailed by the features of individual project management software solutions.  Because the project management process is defined differently by so many organizations, the basis of comparing one solution to another usually comes down to a head-to-head comparison of features and functions.  Although these are important considerations, the real conversation should be focused on business value—and that conversation shouldn’t necessarily revolve around Gantt charts and the particulars of how a software does capacity planning.

Don’t get me wrong.  Any software that doesn’t offer the fundamental feature set required to actively manage a project portfolio shouldn’t even be considered.  It’s like showing up to a gunfight with a knife.  And, if that’s the only consideration, choosing the right work management solution boils down to whether or not you are lucky.

In my opinion, determining whether or not your project management solution provides real business value boils down to a few very important considerations:

1. Does the solution help me (provide a process or methodology) establish a criteria for evaluating potential projects to determine the ultimate value or risk to my business?
2. Will it help me ensure that every potential project is evaluated by the same criteria?  And only those that meet the criteria will be pushed forward?
3. Will I be able to drill down into real-time data to validate that the business initiatives worked on by project teams are those that have been determined to provide the greatest value?
4. Is it easy enough to use that individual members of my project teams don’t need a Masters Degree in project management to use it? (If it isn’t easy for team members to use, they won’t.  Which means, business leaders won’t have access to the accurate and current data they need to make informed decisions.)
5. Does it help my project managers facilitate collaboration and efficient teamwork?
6. Will it successfully integrate with my other business-critical systems?

Keeping people busy is never a problem for most businesses.  The trick is keeping people busy and focused on those things that will drive business value.  If your looking at enterprise project management software that doesn’t help you do that, put the knife away and stay out of the OK Corral.

What do you think?

The new Team Member license enables those individuals who only need status update, time entry, and attachment capabilities the ability to use @task.  When used in combination with AtTask’s full-featured Professional or Enterprise licenses, the Team Member license will enable companies to streamline collaborative processes and increase effectiveness across a broader population of project managers and participants.

Click HERE to read the press announcement concerning the new license type.

Click HERE to learn more about the Team Member license and how it compares to AtTask’s Professional and Enterprise licenses.

I think it is universally understood that a project manager’s job includes the following three mandates:

1. Manage project scope, costs, scheduling, and product quality
2. Identify and mitigate risks, manage project issues, and generally keep project teams on track
3. Manage the team, often a diverse group of individuals, to achieve the goals of the project

Project portfolio management software has the potential to make a number of these challenges easier for project managers.  The right software, as we discussed yesterday will make it easier for project teams to engage in the process and hence easier for PMs to accomplish their objectives.

With that said, the next generation project manager needs to be an exceptional communicator.  As organizations expand globally, I speak regularly with customers who are managing teams all over the world.  With language, cultural, and time zone challenges, today’s project managers need to overcome a lot of barriers to team collaboration and communication.

The most important skills aren’t the ones taught in preparation for an exam.  The soft skills of managing people are every bit as important as managing practice and process.  In fact, the project manager who understand that driving business value is more important than simply driving projects to completion is worth his or her weight in gold.  It’s more than just finishing, it’s meeting customer needs by helping the team work together effectively.

Those things that are considered project and portfolio management best practices are evolving.  It’s not so much about waterfall or agile, but more about making project teams as effective as possible and focusing on projects that drive the most business value.

Although in my opinion, project management software can make this easier, I’d like to hear your thoughts.  Who are the most successful project managers in your organization and what are they doing that is different from those who are less successful?

If you’d like to read about what Rawlings is doing to manage global teams in the US, China, and Central America; click HERE.

For those few organizations who only need some kind of centralized task list, there are a number of choices that are inexpensive and available on-line.  For the rest of us, choosing the right solution will take a little more thought—whether you are looking for an on-line solution or not.

There are a number of huge PPM software vendors who have done very well for many years at providing project managers with the ability to push information up to the executive suite for decision-making.  In fact, as I’ve talked to project managers, many of them have been able to keep  pretty busy collecting project data to push up into executive reports.  Unfortunately, it begs the question, is that what a project manager is supposed to be doing?

These legacy PPM systems force project managers to manually collect the data their executives demand for decision-making, and largely ignore the needs of individual members of project teams.  It might not be intentional, but by making their systems cumbersome and difficult for end users to use, they are virtually relegating a project manager to someone who does nothing but collect and report status—and guaranteeing that executives won’t have accurate and up-to-date information.

Addressing the needs of individual project team members becomes critical for organizations that really want accurate project information.  It just doesn’t make sense to force project teams to jump through hoops or navigate a complicated maze of procedures to update task status.  Making it easy for individual team members to participate in the process, without making them become project management experts, will allow them to participate.

What’s more, in my opinion, a project management software that automatically pushes status information into reports and dashboards every time a team member updates task status, virtually guarantees that business leaders will have accurate and up-to-date information.  What’s more, it will allow project managers to do what they do best—ensure the viability of every project they supervise.  In this economy, it’s often the accuracy of the data available to executives that will make the difference between a profitable company and one that is failing.

When looking for project software, I think it’s critical to include the following criteria in your software evaluation:

1. Does the solution address ease-of-use needs for end users?
2. Does the solution automatically push project status information into reports and dashboards that executives can use to make data-driven project decisions?
3. Or does it force project managers to manually input data, duplicating effort, and forcing them to ignore their primary responsibilities to keep projects on track and manage project teams?

Although these three questions are only a few of the questions you’ll need to ask as you evaluate the available project management software solutions, they are all questions that should be asked before you make a purchase.

What do you think?  Tell me about your experience?

If you’d like to see what @task is doing to make it easier for project teams to update tasks and input status; click HERE.

Don’t forget, you can also follow us on Twitter and Facebook.

Since joining AtTask, I’ve come to appreciate that there are many businesses who rely on project based work to be profitable, and they use project management methodologies—they just don’t call it that.  Whether your organization does formalized projects or depends on short-time-line adhoc initiatives to get things done, let me share something I’ve observed successful projects have in common.

My grandmother used to say, “Well begun is half done.”

I think that’s true of all the work we do, regardless of whether you are using an online project management solution like @task, or sticky notes and a spreadsheet.  To be successful, you have to work on the right stuff.  Keeping people busy isn’t the answer to being successful, anyone can do that.  Keeping people busy working on the right things is how project based work helps make a business profitable.  The question then becomes, “How do I do that?”

If your organization is like most, your “project teams” have a lot of competing demands for available resources.  Sifting through which projects you’re going to tackle and which you can’t is a challenge.  Here’s where I would start:

1. Create a formalized evaluation process for potential projects.  It should include things like, what kind of value does this project provide our organization, how much will it cost, what are the risks associated with project failure, is there anything we can do to eliminate or mitigate those risk, and do we have the resources we will need to complete the project on time and on budget?
2. Establish a committee of stakeholders who’s responsibility it is to formally evaluate every project, based upon the answers to the above questions.
3. Ensure that anyone who has a potential project for consideration formally answers those questions for their project to be considered.  If they aren’t able or willing to do so, their project is rejected—regardless of who they are or the position within the organization they hold.

These three suggestions will help you know that every project undertaken by your organization is “well begun.” And, you’ll have the confidence of knowing that your “project teams” are working on the right projects.

What do you think?  Are you finding success with a formalized evaluation process for potential projects in your organization?

If you’re interested in seeing how @task addresses the project evaluation process, click HERE.

Let me tell you about Buckman Labs.  They set the goal for an enterprise-wide implementation of project and portfolio management best practices throughout their organization.  In fact, managing all their projects, for IT, R&D, HR, or Finance, within a a portfolio of active projects has become critical as they evaluate whether or not each individual project aligns with their company’s strategic goals and objectives.

“Our primary goal is to determine which projects are aligned with corporate business goals and will deliver the greatest business value before they even begin,” says Paul McGriff, Manager of Governance and Administration for Buckman.  “In fact, if someone presents a potential project that doesn’t tie into a strategic initiative, we ask, ‘why are you doing it?’ It’s that important to us.”

I’ve observed that the success of any enterprise project management initiative largely depends upon how well potential projects are evaluated for inclusion within the portfolio in the first place.  Buckman has been very successful.  “The implementation of @task within our global IT department has been very successful,” says McGriff.  “The R&D department has also rolled out globally, and we plan to phase in the entire organization by the first of the year.”

If you like to read more about Buckman’s success, you can read their case study by clicking HERE.

You can also follow us on Facebook and Twitter by checking out the links on the right.

The need to better manage project based work has many companies looking to project management methodologies to help their organizations be more productive.  It would appear that if you work in the project management field, have a strong foundation in best practices, and a good handle on the available software tools, your skills might very soon be in great demand.

I’d like to hear about what you are hearing or reading?  How is your organization coping with the challenges of the current economic climate?

Don’t forget to check us out on twitter and facebook.

After countless interviews with our customers discussing their challenges and successes, I have discovered that those who look at their PPM software implementation as a means to better adopt sound methodologies tend to find success much quicker than those that don’t.

Although executives know they need to have a handle on projects and need visibility to make informed decisions, purchasing a software solution alone  to accomplish that may not be the silver bullet they hope for.  Software is merely a tool for implementing best practices.

Establishing a sound project management methodology prior to implementation will make it easier for your PMO, your project teams, and your organizations.

What is your experience?  Tell me about your successes or challenges.

You can read more about proven best practice implementation and adoption success HERE.

RISKS

Vendor Lock-In—Moore suggests that there are only a small number of vendors today, and most are interested in building a binding relationship through a comprehensive offering.  (Depending on the vendor, this could be good … or not so good.)

Technical Immaturity—Because every vendor has its own user interface, services, and costs, “The unfolding nature of the platform-as-a-service approach puts everything at risk—costs could change overnight, services could be dropped, and quality of service could worsen,” says Moore.  “Would you bet a critical application on such a new arrival?”

Privacy and Control—Although vendors offer extensive protection methods of your data, Moore suggests that you, not the vendor, still own the risk.

Misjudging “Flexibility and Power”—Like outsourcing, Moore suggests that PaaS doesn’t offer flexibility, “Instead, it gives power and ready-made services.”

BENEFITS

Testing is Deployment—According to Moore, cloud computing gets development teams very close to trying multiple machines, different configurations, and different locations, allowing them to test compatibility, performance and response in ways that you can’t accomplish on a local host.

Dynamic Allocation—Moore asserts that cloud computing will allow modern IT teams to “… all but flip a switch to turn up a new service or features, or test it on a small segment of customers.  Before cloud computing, that was unthinkable.  Now business IT teams can approach the ‘perpetual beta’ for which Google is know.”

Internal Entrepreneurship—“The biggest strategic benefit is that developing through PaaS, combined with quick deployment on infrastructure online, can empower visionaries in any part of the company,” says Moore.  “Consider creating a cloud budget, letting teams experiment with cloud computing resources, and see what they dream up.”

This is one in a couple of articles written on PaaS, and published by InformationWeek, that I found interesting.  If you’d like to read this article in its entirety, click HERE.

I agree with Ivanenko when he suggests that the following considerations will help your project-status reporting run smoother:

Timelines—When you do your reporting is as important as what you are reporting.  “Pick times that will most benefit the stakeholders,” suggests Ivanenko.

Fact-Based Information—Make sure the information you are reporting is accurate and trustworthy before your presentation.

Relevance—“Know who you are reporting to and what information is relevant to that stakeholder,” he asserts.

Appropriateness—Ensure that the information you are presenting is appropriate for the audience you are presenting to.

Presentation—Spend some time identifying the best medium for your presentation.

Knowledge—If you don’t have the full details of what you’re presenting, make sure you have someone there who does to help with the presentation.

Audience—Ivanenko suggests, “Focusing on specific individuals or groups allows you to provide relevant and appropriate information.”

Taking a little time to consider each of these elements before your next status meeting will help make your presentations more effective.

To read Ivanenko’s blog in its entirety; click HERE.

Hillson describes the triage process as a simple way to identify and categorize risk.  When emergencies go into the hospital, the first thing they do is triage the patients to determine which people need to see the doctor immediately and which patients can wait.  “Decisions might be made on the basis of the severity of symptoms or the urgency for treatment,” he says.  “The medical triage decision is often made by a junior professional following simple guidelines, dividing patents into two or three groups for further attention.”

He also suggests that the energy industry does the same thing when classifying potential oil fields for exploration.  The use a 3P classification: Proven, Probable, and Possible.  Using this system, oil companies can determine whether or not there is a high degree of certainty as to whether or not oil can be recovered commercially.

“These simple prioritization schemes contrast sharply with the level of detail found in most risk processes,” he says.  “It is common for project teams or managers to argue at length about whether the probability of a particular risk occurring is 10 percent, 12 percent or 15 percent, and to debate whether the most likely impact is $10 million or $11 million.  Even when generic scales are used, people can spend a lot of time disputing between rating a risk as Low or Medium.  Perhaps we can learn something from the medical triage approach or the energy sector’s 3Ps.”

Hillson suggests that the importance of prioritizing risk is not to obtain a precise estimate of the exact likelihood of a particular risk, but to focus on those that require urgent management, and then deal with other important risks, and monitor the others.  A complex risk assessment isn’t necessary to accomplish that.  “We should be careful not to seek more detail we need for this purpose,” he argues.

Quoting Leonardo da Vinci, he writes, “Simplicity is the ultimate sophistication.”  When it comes to prioritization he suggests that “…this is good advice.”

To read the article it its entirety: click HERE.

We don’t often learn much about managing up the corporate chain, so I thought you might find this interesting.

Help Me Help You

“In other words, if you have a problem that needs to be solved, bring me some possible solutions to go along with the problem,” says Sisko.  “Yes, my job is to clear hurdles that get in the way of progress, but I’m not (and simply can’t be) solely responsible for solving every single problem that comes through the department.”

Sisko acknowledges that not every problem has an immediate or obvious solution, which is why he is there to help make sure that efforts can continue without impediment.

Understand the Financial Climate

Taking initiative and making independent decisions is very important, but it’s also important to make those decisions with the budget in mind.  “I saw a case in another company in which staffers in an IT department tried to spend close to ten thousand dollars on a solution when hundreds of dollars would have sufficed,” he writes.  “Fortunately, in that case, the CIO caught the purchase before it was actually placed, but the impact on the budget would have been significant, and so would the political fallout as this was during a particularly difficult financial time.”

Often, the CIO lives with financial constraints the rest of IT doesn’t know about.  It’s important that you consider those when making decisions.  However, it’s also up to your CIO to provide a clear picture of the available budget so you can consider such things when offering solutions.

Understand the Political Climate and Organizational Priorities

Sisko agrees that playing politics isn’t fun for anyone.  However, “When the CEO calls, you probably better jump unless there is something darn important keeping you away,” he says.  “Further, when the people from the most profitable project in the company call and need something reasonable, that’s a priority!”

Handle the Routine Things Without My Involvement

Don’t wait for the CIO to be around to handle the routine things.  “I’ve seen a lot of people afraid to make decisions because they’re worried that the boss won’t like it; this is often the result of conditioning (poor management) somewhere along the line and it’s bad practice for management to get into.  All it does is demotivate and demoralize people.”

Argue Your Side of a Debate or Project

A good leader will want to hear your opinion.  But Sisko suggests, “Make sure you keep you tone and comments constructive and respectful and professional…”

Once I Make a Decision, Get on Board

“You should not blindly follow a leader that is making poor decisions,” he says.  “However, there is a difference between a poor decision and a decision with which you don’t agree.”

There will be times when you need to follow the direction of a leader that you don’t agree with.  “I know for a fact that I don’t agree with every decision made by my CEO, but I also respect his right to make the decision—and to face any blowback that could result.”

These suggestions sounded like some pretty common sense advice to me.  If you’d like to read Sisko’s post in its entirety; click HERE.

I think it’s easy for organizations that are immature in the project management process to think that way.  Unfortunately, I think doing so is risky business.

Vaughan suggests that strong portfolio management practices are an important tool for reducing waste and focusing project teams on those projects that best align with corporate strategic and financial goals; and ultimately provide the most value.  Initiating a structured process for evaluating potential projects against predetermined criteria will eliminate marginal projects that should never be started in the first place—reducing wasted time, resources, and manpower.

“Practicing good project management in the area of initiation, planning and execution will increase the performance of your project execution,” writes Vaughan.  “Resources will be better utilized and the team will be more motivated and organized.  This will reduce duplication of effort and ensure that dependencies are dealt with in an optimal manner.”

A formalized post-mortem process, or retrospective, is an invaluable process for learning from our past mistakes and successes.  It’s been said that those who refuse to learn from history and doomed to repeat it.  Creating a process for evaluating every project will help your organization become more efficient.

“Finally,” writes Vaughan, “we need to monitor and control our projects.”  He continues, “As you improve your implementation of project management you will also see an improvement in the performance of your projects.  These project improvements will far outweigh the amount of effort that you put into project management.”

Is project management overhead?  Like Vaughan, I don’t think so.  Reducing waste and improving performance offers quantifiable benefits.  Vaughan suggests, “Therefore project management is a value add.”  I agree.

To read the entire blog; click HERE.

Current economic conditions have business leaders scrambling to maintain profits and competitiveness with fewer resources.  The research suggests that as organizations look for ways to optimize profitability, new product development should be pursued—not avoided.  The challenge is leveraging already limited resources into successful new product development projects.

Aberdeen suggests that the portfolio management practices engaged by the most successful organizations, allow them to enjoy a profit margin that is 2.9 times that of the Industry Average, indicating that “they are making better decisions about their product portfolios that is leading to greater success.”

The research further suggests that organizations that are not utilizing a portfolio management solution will be at a competitive disadvantage and “forego the benefits of 25% more revenue from new products than competitors and a 19% increase in product profit margins.”

Without question, navigating the challenges of our current economic times to maintain profitability plagues business leaders all over the world.  Boucher’s research offers guidance to those looking to achieve greater profitability with a portfolio management strategy that focuses development resources on the right projects while balancing risk.

To read the Aberdeen report; click HERE.

Everyone has had to work with people like this once in a while.  At first your instinct might be to ignore the behavior, hoping it will go away, but according to Savage, you risk the following:

1. Team members will become resentful and think less of you as a leader.
2. Team members will start modeling the behavior of the person who is not being corrected.

Either way, you loose.

Savage points out that there is only one reason people behave in an unacceptable manner—they get away with it.  She asks, “Who’s responsible for difficult people?”

She suggests it’s anyone who tolerates them.  “Every time you give in to a difficult person, every time you choose not to confront him or her, you allow a difficult person to continue this rude behavior.”

We all have a choice as to what kind of attitude we’re going to take to the workplace everyday.  We may not be able to choose our coworkers, but we can choose how we interact with them.  Savage suggests, “If you have a difficult person in your life, set the boundaries, explain your expectations, and then hold that person accountable.  Be calm when you’re doing this.  The person who is calm and asks the questions is the one in control.”

To read some specific suggestions Savage makes regarding dealing with difficult team members; click HERE.

Without a specific definition, it can be pretty subjective.  “I recognize good quality when I see it,” might not be the best way for stakeholders to measure the success of your project.  In fact, I’ve found it to be pretty difficult to deliver a quality project with that measure.  Davison suggests the following “quality factors,” which I believe are worth considering.

“For each quality factor, it is important to establish early in the change life cycle specific, measurable, goals to which all stakeholders subscribe,” says Davison.  “In fact, multiple goals for a given factor may be required to reflect differing stakeholder and functional needs.”

• Authorization
• Audit Trail
• Correctness
• Continuity of Processing
• Service Levels
• Security
• Compliance
• Ease of Use
• Portability
• Coupling
• Scalability
• Flexibility
• Localizability

Some of Davison’s success factors are more obvious or self-explanatory than others, but could be a good starting point to identify your organization’s quality needs.  You can read more about Davison’s list HERE.

Avery writes that there are two reasons for SMBs to move to SaaS:

1. Lower Risk—“It is much easier for a smaller company to adapt to a new system than a business with several thousand employees.  Any potential hiccups would be limited in scope and could be fixed easily,” writes Avery.
2. Opportunity for Business Process Alignment—Quoting Paul Mau, IT Business Edge contributor, Avery writes, “SaaS affords fledgling SMBs the perfect opportunity to align their business processes, often a shortcoming with SMBs.”

I tend to agree with what Avery suggests.  SMBs looking to implement sophisticated software technologies, like project management solutions, will find SaaS PPM software offers a fairly risk-free vehicle for those new to project management methodologies.

To view the original blog post; click HERE.

I think we can all agree that unresolved issues carry with them associated risks.  Ivanenko describes the associated risks thusly:

1. Schedule risks: The project isn’t completed on time because the issues left unresolved have caused delays in project activities or phases.
2. Budget risks: An unresolved issue creates a requirement to redo the work.
3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team.

Ivanenko suggests some pretty common sense ways to make sure you’ve dealt with any project issues before the end of the project:

• Keep track of the issues
• Maintain a list of the risks involved with these issues
• Keep a list of assumptions about them and validate them
• Maintain a list of all changes executed during the project
• Perform quality assurance and close-out any outstanding quality issues
• Ensure appropriate user-acceptance testing and garner signoff on the testing
• Pay attention to the organizational and business environment your project is impacting and any issues that arise
• Notify systems support teams of any impacts that may be caused by your project, directly or indirectly

When I was younger, I knew of a couple of guys who would bury problems in their file drawer, underneath their active files.  They knew the issues were lurking there, but hoped that if they ignored them, they would go away.

Unfortunately, they never went away, and in fact, only got worse as time progressed.  As much as they tried to hide them, their problems were always eventually discovered.  Angry customers, angry employers, and disappointed coworkers had to solve what would have been easy issues to resolve in the beginning—had they not been hidden in the drawer.

I’m not suggesting that everyone ignores project issues and hides them in a drawer, but whether it is a desire to avoid the problem, or being neglectful, or even careless, resolving issues early in the process saves time and money.

To read Ivanenko’s blog in it’s entirety or to visit the PMI website, click HERE.

Knorr writes that Bill Miller, associate vice president of finance at Nationwide Mutual insurance, “enjoys just such a position, leveraging previous roles in both IT and finance for an organization with a nine-figure IT budget.”

For organizations like Nationwide, offers Knorr, “Getting the full cost picture has been a complex, evolutionary process.”

Miller’s goal was to roll together IT services into a business services catalog that made it easy to understand the underlying details that make the costs of business services obvious.

Knorr suggests, “The ability to trace the effects of business decisions gives IT a new point of leverage.”  He continues, quoting Bill Miller of Nationwide Insurance, I’m not sure the business likes the visibility.  Now, if a business leader says, ‘I don’t know what … is going on over there—some IT guy is doing it,’ IT can say, ‘No, actually, you requested this new functionality.  You thought it would really be a cool idea that would drive revenue, and it didn’t.’ They’re not real thrilled about that.  It’s an accountability thing.”

Knorr offers that Nationwide’s Miller sees cost management as an area of “rapid maturity.”  The down economy is forcing organizations to look at things a little differently than they have in the past.  “Being intelligent and really understanding what your talking about—it matters so much.”

To read the article in its entirety; click HERE.

Part of what makes a successful project manager is recognizing that there is a point where incremental gains don’t provide enough benefit to justify the associated costs.  I once worked with a graphic designer who was a perfectionist.  Although you might think this is a great trait for a designer (which it sometimes was), it was often an impediment to meeting deadlines and project profitability.  Pacelli suggests, “… good-enough teams get more done because they know not only when to start, but when to stop.”

That being said; don’t confuse the “good-enough” mindset for an acceptance of sloppy work.  It isn’t.  Pacelli suggests the following traits are part of the good-enough mindset:

1. Establishing guidelines—“When taking on a project or task, discuss with the team where the good-enough line lives … Clear guidelines on what good enough means reduces rework and misunderstandings,” says Pacelli.
2. Aligning expectations—Include your stakeholders in the process to ensure that you aren’t missing anything.  Pacelli suggests, “Allow the customer [or stakeholder] to see the potential benefits of being ‘good enough’ such as reduced cost on a contract, taking on another project, or implementing an extra nice-to-have.”
3. Making it a team mantra—“A good-enough mindset encourages team members to watch out for each other from becoming obsessed with particular tasks,” asserts Pacelli.  “Constantly ask, ‘Is this good-enough?’ and be open to a team member challenging you with a good-enough question.”
4. Never sacrificing quality—Pacelli asserts, “Good-enough is not an excuse for substandard quality or shoddy workmanship such as not testing a program.  All work must meet applicable specifications.”

Ultimately, “good-enough project teams,” according to Pacelli, “get more done because they make better choices on where to spend time.”

To read the article in its entirety; click HERE.

Citing a recent survey, conducted by PA Consulting, concerning project performance, O’Connor tries to answer in more scientific terms, the question, “How can your business or team deliver the most effective outcome?”

Quoting Tim Pare, one of PA’s leading program and change managers, O’Connor writes, “… there is clearly a statistically valid relationship between what companies do and what they get.  So when you look at these higher performing organizations, they pay attention across the delivery chain because they ‘get’ that it works like a system, they’ve figured it out.”

Here are some of the survey’s main takeaways:

• Maturity is a key driver of delivery effectiveness, with caveats
• All the practices influence effectiveness, but not all are equal
• Lower quartile performers appear to have focused on a subset of practices: the conventional areas
• Resource and financial management are key differentiators
• Non-centralized planning and delivery models appear to deliver better results
• Focus on what you need to do to improve outcomes

After surveying 100 different organizations, PA suggests that there is “perpetual pressure” to do it better.  “So what do you really need?” asks O’Connor.  The survey identified a range of practices that can contribute to, or impede, the delivery of successful projects:

1. Design Authority—Assurance that the architecture, technical strategies, and standards will deliver as promised.
2. Governance—The decision-making, oversight, and clarity of accountabilities.
3. Portfolio Management—Deployment of good project disciplines to ensure reliable delivery.
4. Workforce Management—Delivering the organizational skill, and personal capability at the right time.
5. Resource Management—The organization, scheduling, and deployment of resources.
6. Financial Management—Budgeting, financial tracking and forecasting to ensure adequate funding.

The survey results assert that, “Becoming more mature in these practices will, in general, improve effectiveness.”

Of course, some practices have more impact than others.  According to O’Connor, “One of the first things they discovered is that organizations in each performance quartile—there were four—exhibited stark differences.”

1. The best performers did everything appreciably better—indicating a focus on getting their organizations to work as a system.
2. The essential differences between 2nd and 3rd quartile firms were in workforce, resource, and financial management—the practices concerned with adequate staffing and funding of the portfolio.
3. The most significant differences between 3rd and 4th quartile firms were in governance, portfolio and project management—indicating a focus on conventional areas of improvement.
4. The least effective—4th quartile—firms did most things poorly (although the Design Authority domain was a relative strength).

Citing the suppositions put forward by the survey, O’Connor writes that improvements can have quantifiable benefits.  The survey results suggest:

• Improved portfolio balance, alignment, and overall benefits of 15%-20% through engagement of the business, consolidation and active management of the portfolio and a focus on outcomes (rather than just inputs).
• Increased delivery reliability by setting stretch targets for delivery and actively addressing performance barriers (with achievements made highly visible to make ‘shame’ of non-delivery more pertinent) delivery rates increased from 52% to 95% in 18 months.
• Allocation of appropriate people to work—effective matching of the right skills to projects enabled a technology consulting firm to cut project completion times by 10 % to 40% and overall resource requirements by 24% to 40%.
• Greater utilization and value-add through a combination of resource pooling, formal allocation, and time tracking.  One client, they say, increased the proportion of time spent on project activities by 30%; increased proportion of this on highest value projects by 40%.
• Appropriate use of external resources.

Some of the quantifiable benefits have included: enhanced focus and objectivity, improved business planning, and greater stakeholder commitment.

To read the article in its entirety; click HERE.

Levinson writes that after surveying 400 organizations the project success rate declined and the failure rate increased during the past two years.  “Specifically, 32 percent of IT projects were considered successful, having been completed on time, on budget and with the required features and functions,” she says.  “Nearly one-in-four (24 percent) IT projects were considered failures, having been cancelled before they were completed, or having been delivered but never used.  The rest (44 percent) were considered challenged: They were finished late, over budget, or with fewer than the required features and functions.”

According to the Standish Group, success rates steadily rose from 1994 to 2000, when they dipped for two years, but had began rising again from 2002 through 2006.  “The last time The Standish Group released its CHAOS findings, in 2006, 35 percent of projects were successes, 19 percent were failures and 46 percent were challenged,” Levinson says.

Jim Johnson, chairman of the Standish Group was so surprised by the dip that he intentionally waited and extra four months before releasing the report to make sure the findings were correct.  “He attributes the increase in IT project failures to the recession, which according to economists began in December, 2007, and subsequent budget cuts,” writes Levinson.

Although there are a lot of projects that have been cancelled because of financial issues, Johnson suggests that it’s not necessarily a bad thing.  The trouble for The Standish Group is figuring out which projects were cancelled because of the economy and which were cancelled because they weren’t running smoothly.  “Johnson estimates that 20 to 25 percent of the failure during the past two years was caused by the economy forcing project cancellations,” writes Levinson.

Johnson also suggests that the recession has engendered a risk aversion inside organizations that is slowing down projects.  And the longer it takes to get a project finished, the more likely it is to have serious problems.  “The end result of too much governance is a project that takes so long that stakeholders lose interest and eventually decide to cancel it, or a project that eventually gets delivered but doesn’t get used because it’s no longer relevant to the business, he says.  In both situations, the project is considered a failure,” says Levinson.

However, the news isn’t all bad.  According to Johnson, “When we look at challenged projects, we’re seeing fewer overruns, and the waste to value ratio didn’t look too bad even given all the cancellations.”

To read the article in its entirety; click HERE.

Smith suggests that there are a number of factors that affect the transformation to self-organized teams.  They include anything from the willingness of project sponsors and the makeup of the project portfolio.  Although there is no silver bullet, the following 10 steps create a framework for designing the transition:

1. Assess the Situation—The first step is to completely understand that current situation.  Although that might sound obvious, many organizations will leap forward to Step 27, when they are now at Step 7.  Knowing were you are at now is critical to making any organizational change.
2. Consider a Pilot—Self-directed teams aren’t always well accepted by managers who like the control of managing everything.  “Depending on the norms of the organization, the pilot might be a hidden team or a more more visible project,” says Smith.  “Pilots are not usually conducted on high-stakes projects.”
3. Clarify Requirements—This is another factor that is often overlooked because it is very obvious.  Clearly identifying the requirements is the first step in any project.
4. Define the Nature of the Work—“The nature of the work drives the organizational style,” says Smith.  Questions you might ask could include, is this repetitive work or creative work within a repetitive framework?
5. Facilitate Team Formation—Smith suggests that a working kickoff event can be a great way to allow teams to self-organize.
6. Select the Team—Sometimes teams may need to recruit other they have worked successfully with in the past to complete the teams.  “It’s no different than a new CEO hiring past colleagues or new managers bringing in people they believe can contribute the most to the success of the team,” argues Smith.  “In self-selecting teams, the difference is that this process is performed in the open.”
7. Establish Communication Rules—This is another step that is often overlooked.  You’ll need to define what communication options are available and how time-sensitive or critical communications will be delivered.
8. Declare Commitments—Metrics and measurements are very important to provide focus and keep everyone on track.  “Each team member should set personal commitments on a monthly basis—not as major as end dates, but also not too small,” says Smith.  “These mid-range commitments are the ones that affect several teammates and are important to the forward progress of the project.”
9. Control Meetings—Keep them short.  Status updates should take no more than a few minutes.  If there are impediments to forward progress, take them offline so as not to waste the time of those who aren’t involved.
10. Take a Step Back—“Periodically, the team should take time to step back from the daily work and talk about how the team is working,” he suggests.  “This review should involve all of the team members, and it should take on the tone, importance and urgency of ever other project task.”

What are your experiences with self-directed project teams?

To read the article in its entirety; click HERE.

In fact, Glen suggests that some projects don’t really need a sponsor. He makes the argument that infrastructure projects, for example are unlikely to even attract a sponsor. Comparing it to refurbishing the restroom he argues, “Everyone wants a toilet and a sink, but no one thinks they’re mission-critical infrastructure until they’re no longer available.”

On the other hand, there are projects that are doomed to failure without a sponsor.

“Even when we do recruit sponsors, things don’t always work out well,” he says. “Simply having a sponsor is not enough to ensure success.”

Glen offers the following two issues with sponsors that often contribute to project ineffectiveness:

1. Sponsors and project managers fail to clearly define the sponsor’s role—You might think that a sponsor would automatically know what he or she is supposed to do, buy you would be wrong. Business people are rarely familiar with project management processes and a discussion of what is expected of a project sponsor is always a good idea. Even if they are regular project sponsors. “The absence of clarity can lead to some misconceptions, on either side, about the nature of the sponsor’s authority.
2. Sponsors who become politically disconnected from the business community—A sponsor who doesn’t have the connections within the organization to push issues forward won’t be of any worth to the project. “If we don’t monitor the sponsor’s connection to his constituents, we wn’t know when one starts to peel away from the other,” says Glen. “And, if the gap between the sponsor and the business grows, then the gap between the project and the business grows too.”

Managing the sponsor relationship is often critical for projects to be successful. Make sure they know what you expect from them and that they are “plugged in” to what’s happening in your organization. Otherwise, suggests Glen, “If your sponsor is unplugged, your project will be too.”

Click HERE to read the article in its entirety.

“AtTask is emerging as an innovator in business productivity,” said Scott Johnson, CEO of AtTask.  “We are thrilled at the number of companies who are recognizing the value PPM brings to business and who are turning to AtTask as their solution of choice.  This growth is a result of having the right solution at the right time.”

AtTask continues to grow despite a lagging economy by helping companies focus on those activities that make them more effective, innovative, and competitive.   We expect to see the trend continue as more organizations realize the importance of project management software to collaborate and accomplish the work most essential to the enterprise.

To read more about AtTask’s place on the Inc. 500, click HERE.

Accurate and detailed reports are important, but Bourne is right, most executives want the 20,000-foot view—that’s all they normally have time for.  She makes a few suggestions that might help:

• “Separate push and pull communications.”  Make the detail available someplace where people who need it can easily retrieve it (pull).  Anything you send out (push) should focus on the highlights and the information that requires action, suggests Bourne.
• “Separate history from future.”  Reporting on what happened last week is of no value unless it contains information that could influence future decisions.  Bourne suggests that historical data is important to accountants, but business leaders, project leaders, and team members need information that is forward-looking and focused on any action items.
• “Focus on the needs of the receivers.”  She asserts that it’s important to give the audience the information they need to help make the project successful.  Everyone on the project team doesn’t need the same information, “Team members need to know what work to do in the next week or two.  Managers need to know what they have to decide.”

This kind of communication doesn’t just happen.  Successful communication requires effort.  And remember, to ensure the successful completion of any project, you need to focus your communication efforts on the important stakeholders that influence project success.

To read Bourne’s blog post in its entirety; click HERE.

As a result, Leffingwell suggests the following ten practices that can be applied to any knowledge work development:

1. “Develop and empower self-organizing, self-managing teams.”  When teams are empowered with an understanding of the mission and vision of what they are working on they are better able to meet expectations.  Sir Francis Bacon said, “Knowledge is power.”
2. “Plan to work in short (one- or two-week) iterations.”  Planning work for completion in smaller increments allows team members to feel a sense of accomplishment and enables managers to keep projects on schedule; as well as help teams that are struggling earlier in the process.
3. “Focus on value delivery.” I know of one company that is so focused on the business value associated with every project that if a business goal can’t be identified, they ask, “Why are we doing it?”
4. “Develop a single prioritized work backlog for the team.”  Designating a product owner and establishing a public backlog of potential projects allows business leaders to prioritize potential work based upon business goals.  This keeps project teams focused on only those projects that provide value.  (See #3.)
5. “Apply daily 15-minute standup meetings as a primary form of communication and commitment.”  “Standup” because the meeting is held with everyone standing.  This keeps the meeting short and focused on the three key reasons for having the meeting in the first place, “What I did yesterday, what I’m doing today, and what are my impediments to accomplishing my tasks?”  Anything over 15 minutes is too long.
6. “Minimize the work in process to increase productivity.”  Plan projects based upon real-time estimates of what is doable.  If there isn’t the manpower for a specific task, it will have to wait until next time.  The point is to work on projects that can be completed in the time designated or portions of larger projects that can.
7. “Plan for delivery of larger enterprise initiatives in larger (release) time boxes.”  Engage stakeholders periodically (approximately quarterly) in planning, visioning, and establishing commitments.  Make the vision, objectives, and commitments visible and public.
8. “Provide total, real-time visibility.”  Build a big, visible chart to show work in process and individual and team responsibilities. Publish your plan and release objectives.
9. “Develop shared knowledge.” Avoid over-specialization so everyone on your team can work together to accomplish objectives. (This could be problematic for some teams, but where possible try to pair up those with similar skills so there isn’t an undue reliance on any single team member.)
10. “Apply work physics and Agile planning.” Estimate and track the time and effort that will be required to successfully complete each task (or story).  Establish and apply a “team velocity,” which is a representation of current capacity and what is achievable in a specific timeframe.

“Most of the core principles of Lean and Agile software development apply equally well to other enterprise knowledge work projects and activities,” writes Leffingwell.  “I believe you’ll find these practices to be unambiguously good, and they’ll help you achieve many of the productivity, quality, and morale benefits that every enterprise covets.  Feel free to ‘try these at home.’”

Although it may require some modification to suit your particular needs, I’ve seen Agile methodologies work very well outside of software development.  Agile methodologies are great for organizations that want to pursue those projects that 1) are prioritized by business value, 2) have specific human resource requirements, and 3) improve the productivity of their project teams.

To read the article in it’s entirety and learn more about Agile methodologies; click HERE.

Davison presents a scenario where an executive says something like this, “You did a great job managing ABC project for us last year and I’d like you to be involved in a new initiative we’re planning.”

He or she then goes on to describe in glowing detail all the potential benefits of the new project and suggests, “You did a great job of estimating and controlling the delivery of ABC project within budget and on schedule.  You’re a pro!  That’s why I’m involving you!  I need a ballpark number of our new project.  Don’t worry, we won’t hold you to it but we just need a rough cut of the costs and the timeframe for our pitch to the Executive Committee.”

I bet this can-of-worms sounds familiar, doesn’t it?  According to Davison, the ensuing conversation should probably go something like this:

You: “Well, how much can you afford?”

Executive: “What do you mean ‘how much can I afford?  I’m just looking for a ballpark number here!”

You: “Well, the amount you can afford to spend will influence the alternatives we consider and that will be a major contributor to time and cost.  For example, if the change is worth $100K to the organization, we won’t even consider the million dollar solution.”

Executive: “So, how do I go about figuring out what the change is worth?  We have the Executive Committee presentation in a week!”

You: “There are three things you need to consider to arrive at a value of worth: 1) what’s the projected bottom line impact that you’re hoping to achieve, 2) how quickly do you need to reach the payback point, and 3) are there other changes, planned or in progress, that you’re dependent upon or competing with.  Once you’re determined the worth, you can use that number as a proxy for the cost and indicate to the Executive Committee that you’ll be evaluating alternatives that can be delivered within that number.”

Executive: “Sounds reasonable!  Can you give me some time to help come up with a figure for worth I can live with?”

You: “Of course!”

Davison asks you to consider the difference between this type of conversation and those that typically happen in this scenario.  He also details a number of positive forces that have been put into motion that can ultimately help this new project succeed.  “Remember to ask the question, ‘What is this change worth?’” suggests Davison, “and make sure you get an answer that all stakeholders acknowledge.”

To read the article in its entirety; click HERE.

Griffiths continues, “Just as agile zealots like to berate the command-and-control nature of some PMI approaches, old school managers condemn the seemingly unstructured techniques practiced in agile.  In reality, projects and organizations are complex and a smart mix of approaches is required to be successful.  Really, who does only pure agile and who does only pure waterfall or command-and-control projects, anyway?”

According to Griffiths, the PMI Agile Community is a grass-roots initiative that is trying to incorporate agile techniques to help manage today’s extreme projects.

Here are some facts about agile from a survey published in Dr. Dobb’s Journal, June 2008:

• 69% of respondents reported that their organizations are doing one or more agile projects.  Of those who hadn’t started, 15% expected their organizations to do so within the next year.
• Interestingly, 61% of developers think their organizations are doing agile, whereas 78% of management thinks so.
• 82% of those doing agile were beyond the pilot stage.
• Respondents overwhelmingly indicated that agile teams are producing higher quality, have greater productivity, and enjoy greater stakeholder satisfaction.
• Co-location pays off.  Look at the agile success rates for: co-located teams, 82%, near-located teams (people in different cubes, on different floors, or working from home), 72% significantly distributed teams (requiring air travel for members to get together, 60%.
• 84% of agile teams have iteration lengths of four weeks or less; two-week iterations are the most popular.

To read Griffith’s article in its entirety; click HERE.

Jordan suggests that like any other product, it’s important to effectively brand your projects and offers the following:

The Importance of Branding

“To many people, the idea of naming a project is silly—it reeks of some unnecessarily secret approach to use code words instead of simply stating what the project does,” writes Jordan.  “To me, it’s more than that.  You don’t need to come up with some futuristic name—‘star striker’ is no better or worse than ‘duck’ (I have been involved in projects with both of those names).  But either of those names is easier to remember for the uninitiated than ‘VAX upgrade project for Finance.’”

Jordan suggests that branding your project is about identifying it to everyone whether they are on the team or not.  Although it might sound silly, Jordan suggests that it is also a good way to help people come together as a team.  He even goes so far as to suggest the creation of a project logo.  (From the time I was a kid following the Mercury 7 astronauts, NASA has given a name, a logo, and a patch to every space launch.)

He also suggests that something as simple as making your project paperwork stand out could make a difference—“… if someone has to spend 10 minutes searching for a document, then they will associate their frustration with the project.  Is that fair?  No.  Does it happen?  Absolutely.”

Does all this matter?

“Branding the project gives it a sense that it is somehow more real—it’s something tangible that they [project teams and stakeholders] can associate with,” says Jordan.  “The result is a project team and stakeholder community that is a more cohesive unit and who feel a greater sense of belonging.”

Leveraging Your Brand

“It’s not enough to simply name your project and give it a logo, in the same way that Coca-Cola (or any other brand of your choice) didn’t simply stop there,” says Jordan.  “You now need to promote your brand to make sure that people know about your project and care about it.”

Conclusions

Jordan recognizes that you can’t replace good project management with marketing.  He’s suggesting that if you create an image for your project then you are achieving multiple goals:

• You create something tangible for your project team, stakeholders, etc. to associate with, giving them a sense of identity and common purpose.
• You give all project deliverables a common identity; giving the project a sense of substance and making it stand out uniquely from every other project (which are likely using the same document templates).
• You create values for the project which—if done properly—will help get buy-in from stakeholders and will help create a positive image for the project and the people involved in it.

“This isn’t really about creating a name and a logo, it’s about thinking about the image of the project—what it is that the project stands for,” says Jordan.  “The name and logo are just representations of that which helps bring people together.”

To read Jordan’s article in its entirety; click HERE.

To visit us on Twitter, click HERE.

Coursey suggests that a “sue first and ask questions later kind of an organization” probably isn’t the kind of company most people want to do business with, and is probably something you need to consider as your organization makes decisions about where social media will fit into the mix.  He suggests the following five things any business can learn from Horizon’s Twitter lawsuit:

1. “Before suing, ask people not involved with your company what they think of your case,” he says.  He suggests that if Horizon had asked people on the street what they thought of a “$50,000 lawsuit over a tweet sent, apparently, to fewer than 20 people, they’d have been surprised by the reaction of the world at-large.”
2. “Understand that the online world will side with the underdog,” says Coursey.
3. He argues, “Solving customer complaints is often, maybe almost always, less expensive in the long run than fighting.”
4. “The appropriate use of ‘reputation management’ is to make customers happy, not generate lawsuits,” asserts Coursey.
5. And finally, he says, “If you can’t accomplish the first four, just stay away from ego searches for your company’s name on Twitter, Facebook, Google, or even Bing.  You will live a much happier life by not knowing what people say about you.  Trust me on this one.”

As you might expect, Coursey’s advice to Horizon would be “to drop the suit, pay the woman’s legal fees, apologize, and hope she doesn’t countersue.”

I have to agree with Coursey when he suggests that overreacting to criticism doesn’t look good and makes people wonder what you’re hiding.  And big companies suing customers never makes many friends, and will more than likely make a lot of enemies.

To read the article in its entirety; click HERE.

By they way, you can visit our Twitter site at: twitter.com/attask.

The Slow IT movement argues that there is no more “more.”  IT leaders talk all the time about the need to stop doing work with no business value and for organizations to choose projects based upon metrics that reflect those values.  They suggest that IT leaders need to push back when confronted with unrealistic deadlines because doing so might actually benefit your company’s bottom line in the long run.

“The tanking economy is the perfect excuse—use it!” they exclaim.  “Business executives across the globe are using the downturn to justify layoffs, cutbacks, closings, delays, negotiations, and all manner of triage.” The Slow IT movement suggests that you do the same thing and suggests the following 10 tenets of Slow IT:

1. Stop trying to be a superhero—“Unrealistic deadlines and workloads just lead to burnout and poor quality,” suggests the Slow IT movement.
2. Let users manage themselves wherever they can—They suggest that IT not micromanage what users install on their computers, and if they do something catastrophic, they will bear the burden of their own lost data.  “After all, with freedom comes responsibility,” they say.  “And you’ve got more critical work to do.”
3. Eliminate the makework—They suggest that you evaluate all of your routine tasks and assess their value.  Some tasks may need to be put off until really needed, suggesting that it may be “…more efficient to let some things go and fix them occasionally than to spend a lot of effort preventing the breakdown.”
4. Automate everything you possibly can—“Just make sure it’s understood that autopilot only works when the skies are clear.”
5. Outsource your annoyances—“Saas and cloud computing aren’t just the latest tech buzzwords; they’re also ways to avoid managing and maintaining servers, storage, and applications,” they said.
6. Target the sacred cows—They suggest, “Look for every opportunity to eliminate the nice-to-haves for the sake of the truly important.”
7. Let downtime be downtime—When you’re not at work, don’t be at work.  Put the laptop down, and find another hobby.  “Let the weekends and evenings sort themselves out—unless there’s absolutely no other choice.”
8. Refuse to get married to anything—“Hardware, software, home, office, computers, routers, whatever—just because you fixed it once doesn’t mean you are contractually obligated to fix it forever.”
9. Keep the joy of tech alive—According to InfoWorld, “The company is poorly served if you’re a dead geek walking … Don’t get stuck in the hamster wheel of the day-to-day.”
10. Make the business listen to you—“You’ve heard ad nauseam the need for technologists to understand the business.  Well, the business needs to understand you, too.”

This is the first time I’ve heard of the Slow IT movement.  That said, doing more and more with less and less seems to be a solution that is doomed to failure.  At some point the system will just stop working.  What do you think of the movement?

To read the InfoWorld article in its entirety; click HERE.

Weinstein suggests that promoting IT projects in this kind of climate is pretty difficult, but not impossible—and suggests the following:

• Think like a businessperson—The person best able to talk to business needs and benefits improves his/her chances when making their case.  “Translating IT solutions into plain English is a highly valued skill in all organizations,” says Kate LeVan of the business communication consulting firm LeVan Partners.  “The work environment is fast-paced enough, but in tough times there is even less tolerance for patiently sitting through jargon-laden explanations.”
• Learn project-promoting tips from top salespeople—“Successful salespeople are masterful promoters,” says Weinstein.  “The PM who can address the big business issues to promote a project is likely to make a powerful impression.”
• Successful sales pitches end in negotiation—“Rarely do proposals get approved without change or conflict,” he says.  “Knowing how decisions are made in your organization is priceless information that can make or break a project.”
• Think like a decision-maker—“In promoting a project, rather than start with a proposed solution, begin with a conclusion.  Top executives think in sound bytes.  Their ears perk up when they hear about impressive bottom-line results,” says Weinstein.
• Think near term, but envision long-term benefits—No one wants to put a Band-Aid on a problem when a more significant solution is required, but according to LeVan, “That’s noble—and probably ultimately good for business.  But remember that the members of your listening audience have deals to make and jobs to keep, too.  Try to build in a short-term benefits perspective or fix that shows how cognizant your and your team are of the organization’s mission.”
• Get priorities straight—Positioning new and existing projects internally is important.  According to Rick Brenner, principal of Chaco Canyon Consulting of Cambridge, MA, attractive initiatives have the following four attributes: 1) Short-run cost reduction, 2) Cost-reduction efforts that improve current operations, 3) Resource discovery opportunities, and 4) Focus on expensive resources.
• Keep it simple—“Emphasize how a project delivers business benefits executives value most—return on investment, value-added and demonstrable operational improvements,” says Terry Schmidt, president and founder of Seattle consulting firm ManagementPro.

Consider these commonsense suggestions as you promote projects in your organization during these difficult economic times.  To read Weinstein’s article in its entirety; click HERE.

Below are five principles of effective leadership for managing teams in today’s business climate:

1. Lead Yourself First—“If you don’t follow yourself, could you expect your people to follow you?” asks Fritz.  “How you lead yourself can be one of the most critical factors in your success as a leader.”
2. Encourage Ownership—Fritz argues, “There is a huge difference if your people feel ownership for what they are doing versus just ‘renting’ their job … The more your people feel that sense of ownership, the less time they will demand from you.  Ownership comes by defining outcomes for which your people and your teams can feel responsibility.”
3. Develop Role Models—“Key people in locations across your organization interpret your direction for their individual roles,” says Fritz.  “Develop these role models, your interpreters, and they can advocate the direction in which you would like to go.  You cannot be everywhere.  The more time you have invested in helping your role models understand your direction and the reasons for it, the more decisions are aligned with that direction.”
4. Reinforce the “Glue”—Fritz asks, “What three factors drive collaboration within your organization?  You might struggle with the answer.  However the ‘glue,’ the thing that links people and locations together, is one of the most important success factors for all global organizations.”
5. Always Follow-Up—“You get the behaviors you reinforce,” says Fritz.

By utilizing these five keys to successful leadership, you can add a little more TLC to your projects.  To read Fritz’ article in its entirety; click HERE.

1. Learn how to communicate with every level within your organization
2. Learn how to speak publicly
3. Use templates to help complete your documentation and keep consistency—but remember, templates are a guide, not a rulebook!
4. Understand Earned Value Management Systems (EVMS)
5. Get the right resources behind you
6. Manage your stakeholders
7. Learn how to problem-solve with confidence
8. Learn the necessary critical skills to do the job well
9. Formally “kick off” your projects
10. Hold regular team meetings
11. Don’t be afraid of what might go wrong
12. Praise your team for accomplishments…no matter how small
13. Time management is critical
14. Delegate!
15. Capture best practices
16. Put processes in place
17. Be a strong decision maker
18. Join a group of other project managers
19. Formally closeout the project
20. Celebrate

You can read in more detail about all 20 of these suggestions by clicking HERE.

LaBrosse suggests that a clear set of business rules will help you run a tight ship.  Divided into three buckets, here are her rules:

Decisions, Decisions

“The fastest way to move projects along is to make decisions by the majority with the Project Team Leader having the final say when there is a tie,” says LaBrosse.  She suggests the following three-way vote:

1. Agree (thumbs up)
2. Disagree (thumbs down)
3. Don’t agree, but can live with the decision of the majority (thumbs sideways)

Play Nice

Regardless of role, every team member is important.  LaBrosse suggests, “Give credit when credit is due, build trust and encourage all types of participation.”

The Deal Breaker

“Great communication tactics and skills will lead a team to victory,” she says.  “Negative communication will derail a project and leave a sour taste in everyone’s mouth.”

The Benefits of Following the Rules

“People feel good when they are able to achieve goals,” says LaBrosse.  “Clear and obtainable rules empower employees to meet and exceed expectations, build confidence, keep the business on track and contribute to an overall positive work experience.”

When we were kids we played a lot of games with a simple set of rules that keep the game fair.  The same can be true in the workplace.  To read LaBrosse’s article in its entirety; click HERE.

Levinson suggests the following 14 mistakes are common among IT departments:

Staffing Mistakes

• Projects lack the right resources with the right skills
• Projects can quickly grow out of control without a savvy project manager at the helm

Process Mistakes

• IT doesn’t follow a standard, repeatable project management process
• IT gets hamstrung by too much process
• They don’t track changes to the scope of the project
• They lack up-to-date data about the status of projects
• They ignore problems

Planning Mistakes

• They don’t take the time to define the scope of a project
• They fail to see the dependencies between projects
• They don’t consider Murphy’s law
• They give short shrift to change management
• Project schedules are incomplete

Communication Problems

• IT doesn’t push back on unreasonable deadlines
• They don’t communicate well with project sponsors and stakeholders

Understanding potential problems doesn’t do anything unless you have a plan to deal with them.  To read Levinson’s article in its entirety and learn her suggestions for addressing these issues; click HERE.

Raffoni makes three suggestions, which if implemented, will help your organization bridge strategic planning with tactical execution.

1. Communicate the key points—Communicating strategic vision is a challenge for many executive teams.  Raffoni suggests that making sure everyone is clear on the most crucial 80% of the plan is more important than making sure everyone understands the remaining 20%.  “Distill the strategic plan down to its most crucial points, and focus on communicating those,” she says.
2. Develop tracking systems that facilitate problem solving—“The companies that differentiate themselves from the competition … develop measures and other tracking tools not only for planning, but for the execution phase as well,” writes Raffoni, quoting Gordon Woodfall, former president and general manager of Thermo Fisher Scientific.
3. Set up formal reviews—“The odds of successfully executing a plan that isn’t frequently reviewed are slim to none,” writes Raffoni.

Aligning strategic vision with execution requires that executive management and execution teams have top-to-bottom and bottom-to-top visibility into every strategic initiative.  Transparency fosters accountability and allows business leaders to validate ever initiative.

To read the article in its entirety; click HERE.

“The problem with these metrics, according to Forrester, is that they perpetuate the idea that a project is only successful when it is completed according to the initial schedule, budget and requirements—and therefore, that anything less is a failure,” writes Levinson.

Forrester advocates that PMOs take a more active role in managing the stakeholder and sponsors perceptions of project success or failure and advises the following:

1. Keep project steering committees on task—According to Tim Cardin in the report, Debunking IT Project Failure Myths, projects struggle when the steering committee providing governance fails to make decisions or solve problems.  “The PMO is better positioned than the individual project manager to keep project decisions and the necessity of these decisions visible to business and IT management,” he writes.
2. Improve communication with project sponsors about changes in requirements and the impact of those changes on the budget and timeline—“This will prevent project sponsors from viewing projects as failures when project requirements changed and resulted in higher costs,” writes Levinson.
3. Improve the reliability of project plans—“Cardin recommends that PMOs establish best practices for developing plans for projects that involve ‘significant unknowns.’  Such established best practices help the PMO set business sponsors’ expectations for reasonable project performance and reasonable actions for a project manager to take under difficult conditions,” writes Levinson.
4. Better communicate estimates of cost, schedule, and resources—According to Levinson, “PMOs need to more clearly articulate to project sponsors how they come up with estimates for a project’s cost, schedule and the resources it will require, how those estimates are based on certain business conditions, and how changes to those business conditions can impact the cost of and timeline for the project.”

To read Levinson’s article in its entirety; click HERE.

That being said, depending on the type of projects that a small or medium-sized business works on, a PPM strategy might make a lot of sense.  Schmidt suggests, “Some indications that the enterprise needs PPM include: frequent difficulty finding enough people to put together a solid project team; high turnover due to burnout of key contributors working on too many projects; frequent change of status projects (i.e., moving from ‘active’ to ‘on hold’ to ‘top priority’ and back); completion of projects that no longer meet a strategic need; and intense competition, rather than cooperation, among departments when staffing and funding projects.”

Schmidt suggests the following four best practices for setting up grassroots PPM:

1.    Setting up a PPM capability must be done in a series of steps over a phased implementation—Although there are a lot of very good reasons for small and medium-sized organizations to implement a formalized PPM process, implementation can be lengthy and costly.  Schmidt suggests that you tackle the challenge in small bites.  “Trying to implement all aspects of PPM at once requires too much organizational and cultural change and affects to many users,” he says.   Below are the three basic models he suggests:

• High value/easily implemented projects first—“In this approach, the starting point is to select an entire pilot project for the first effort,” says Schmidt.  “Subsequent projects will be added to the mix after this pilot has successfully been used as a test-bed for the PPM process.”  When choosing the first project, you’re looking for an initiative that will provide a lot of business value and be relatively easy to complete.
• System life cycle concept—Schmidt offers, “This model takes all of a subset of projects in a particular phase of the systems/product life cycle (‘concept development’ for instance) and places them ‘under control’ of the PPM process.”
• Domain-based—“Some examples of this approach include implementations by functional area, product area or business unit,” says Schmidt.

2.    A proposed portfolio must match the business reality of today while being able to take into account future trends and challenges—“A project portfolio is a snapshot of the current state of the business,” argues Schmidt.   “To be effective, the analysis and management of the portfolio must add value today as well as tomorrow.  Small and medium-sized businesses in particular cannot carry a conceptual, non-productive PPM capability for very long in today’s business environment.”

3.    Automating the portfolio is less important than the intuitive understanding of the portfolio structure itself—“It is risky for small and medium-sized companies to become overly focused on tools,” he says.  “Over reliance on tools can often channel portfolio mangers into potentially risky approaches to assess the health of projects and products.” To successfully implement a PPM software solution, it is important to completely understand the portfolio structure.

4.    Managing, training, and facilitating the people process from executive level to project level will not be accomplished by itself—Schmidt suggests, “Because PPM represents a new way of doing business, a training strategy must incorporate significant change management.  An initiative as significant as PPM typically requires an organization to implement new roles, processes, and automation.  The changes can appear daunting for many employees whose first experience with the new technique in training class.”

Small and medium-sized business deal daily with capacity restraints and resource needs, which is why PPM offers so much potential.  To read the article in its entirety; click HERE.

Citing a recent poll by PMStudent.com, Finch says:

• 11% of project managers surveyed said they have experienced increased financial scrutiny
• 14% have experienced or witnessed project manager layoffs
• 27% have experienced project cutbacks

Historically, top executives have often viewed the PMO as ‘project management overhead,’ a perception that must be changed if PMOs are to survive these widespread cost-cutting measures,” writes Finch.  “When PMO managers align projects with company strategy, deliver positive results and demonstrate their value to management, they put themselves in a much more secure position within the organization.”

The Projects—According to Finch, when money is tight, “…the projects that do not align with company strategy have to go.  In fact, the economic recession presents a compelling opportunity to get rid of such projects.  Prioritization of projects is a service that the PMO can deliver which is sorely needed.”

The Results—“The PMO must not only choose the right projects to work on, but also ensure that these projects are successful,” says Finch.  “In good times and bad, you need successful execution across the board.”

The Value—“Another key to PMO survival during rough times is effectively communicating the value of your projects to management,” he says.  “Project managers who recognize this and use it to their advantage will have staying power, while others will not.”

New Respect for the PMO—Finch suggests that the best way to avoid being viewed as overhead, is “to deliver real value to the organization by focusing on the right projects and executing them successfully.”  He continues, “PMOs today have a choice: they can either justify their existence by highlighting their achievements and illustrating their true value, or they can fall by the wayside when cuts are made.”

To read the article in its entirety; click HERE.