Janis Rizzuto is Contributing Editor of ProjectsAtWork. We loved her latest article on Agile where she interviews Scott Ambler, chief methodologist for Agile and Lean with IBM Rationaland. We wanted to share a summary with you here. Head over to ProjectsAtWork for the full article.

Looking to learn from someone with a consummate résumé in the agile space? Look no further than Scott Ambler. Ambler is chief methodologist for Agile and Lean with IBM Rational, working with customers around the world to help them understand and adopt software processes that are right for them. He is the founder of the methodologies for Agile Modeling, Agile Data, Agile Unified Process and Enterprise Unified Process, and the creator of the Agile Scaling Model. His latest work is around Disciplined Agile Delivery, which he describes as “people first, learning oriented and enterprise aware.”

A prolific author, Ambler has received awards for several of his 19 books, and he is currently a senior contributing editor for Dr. Dobb’s Journal. In the electronic publishing world, he has a blog on the IBM site, Agility@Scale, and a personal website with deep resources on agile methods and trends.

ProjectsAtWork tapped his expertise to provide a view of the current and future state of agility. His key message: Scaling agile to the enterprise is essential.

You attended the anniversary meeting for the Manifesto for Agile Software Development. What was your impression of the event and its significance?

I thought it was a bit too short. We needed another half-day. This year’s group was more diverse than the original group who authored the manifesto 10 years ago. People discussed their experience with what is working and what is not working. There were a lot of good ideas. I hope we will do it again and not wait 10 years.

Reflecting issues for Agile’s future, four belief statements were written at the meeting. Does any one of them matter more than another?

Yes, the statement to “maximize value creation across the entire process” is the most important to me. It reflects Lean concepts and the concept of optimizing the whole. We need to look across the entire IT spectrum and into the business domain, to figure out how to be more efficient and effective there.

In mainstream agile methods, everyone focuses on what they find interesting: Scrum focuses on project leadership and requirements management; Extreme Programming focuses on technical practices; agile modeling focuses on modeling and documentation; and agile data focuses on database techniques. Those are all good things and important pieces of the puzzle, but none of them address the full puzzle. The full puzzle is how do we deliver a working solution following agile techniques? How do we become more lean and agile at the enterprise level? Right now, we are too narrowly focused.

Read the rest of this great interview here.

What project accounting is and why it's important

Project accounting is a critical concept for today's business world, yet most businesspeople do not know their project accounting data. This includes firms that outsource the accounting of others and it results in cost ignorance. Most modern firms have very little understanding of which customers are profitable for them, and which ones are huge losers. R&D projects which should have been cancelled long ago linger on. IT departments languish amid derisive commentary from their peers.

Proper project accounting is one of the many things in life that sounds really easy but, for various reasons – psychological, sociological, political – can often be really hard.

Globalization is just getting started – and it's set to accelerate

The scariest thing about this – for Americans – is that today, there are 1 billion knowledge workers on the internet. Many of them are from countries full of smart, well-educated people who are really tired of poverty.

There are 7 billion people on planet Earth. Today, there are 1 billion knowledge workers. Soon there will be billions more. They'll all be very motivated to figure out what you're up to and how they can do it better, faster and cheaper.

How exactly do you think you're going to stay in business when you don't even understand your costs on a per-project basis? How about your customers? Will they be around and survive the coming tidal wave? In the immortal words of Neil Peart, "Constant change is here to stay." Globalization is accelerating.

It's time to get ready.

We're all bad at project accounting

In my position as CEO of a company that helps people solve these problems, I've seen every kind of company all over the world with various levels of ability trying to attack and fix this issue. Small companies, large ones, consultancies, manufacturers, from South Africa to Sweden to Jordan to New Zealand – nobody understands their costs. Their ability to fix it is not related to the industry they're in or the size of the company. The key differentiator here is the ability to effectively communicate the benefits of the collection of this data to the front line knowledge worker.

Why are we all so bad at project accounting? I've thought about this a great deal and the answer comes down to "future shock" – a term coined in a book of the same name by the sociologist/futurologist Alvin Toffler in 1970. Future shock is a perception of "too much change in too short a period of time"

Our sociological ability to implement effective accounting systems hasn't really caught up with change in the last 50 years.

From Neanderthals to Farmers

Read the rest of this article at The International Community of Project Managers

Project budget status is something that should be reviewed regularly, forecasted weekly, and distributed to all key players on the project. If key project personnel aren’t aware of the status of the project financials throughout the engagement, it’s much harder to hold them accountable for what they’re spending on the project. Subsequently, it’s harder to get their help in keeping the project budget on track.

So, given that it’s the customer’s money you’re spending on the project, you’d assume that they always want to know the budget status, right? Well, not always. I’ve had at least three projects in my long history where the customer really didn’t want to have anything to do with budget status and reporting. Whether it was sort of a ‘don’t ask, don’t tell’ situation, or ‘what I don’t know won’t hurt me’, or ‘I don’t want this information in the hands of my team so we’ll keep it quiet’, I’m not exactly certain – each gave differing reasons for refusing ongoing knowledge of the budget status. The most recent example was a multi-million dollar software implementation for a large industrial equipment supplier. The project sponsor – who was mainly a figurehead on the project – wanted the info periodically, but didn’t want anyone else to have it. It was a frustrating situation for me as the project manager – feeling secretive is not a situation that I like to be in with anyone on the customer’s team.

As the project manager, what do you do in these types of situations? What if things start to go poorly and corrective action needs to be taken to salvage the project budget? Then you’re working with a customer who will be surprised or stunned by this information. They won’t likely be your allies in fixing the situation because they haven’t been following it like you have – they’re outsiders up to this point as compared to the project manager. I guess no knowledge = no responsibility…but really?

When I was in this situation, I followed these three steps:

1) As requested, I created two different versions of the status report – one with the budget info that went to my team and one without the budget info that went to the customer team.

2) I made sure that senior management had my status report – including detail on the project financials – each and every week. If it appeared that there was going to be a budget issue, I let them know as proactively and as far in advance as possible. If the customer won’t be my ally on the budget, then the next best thing is the PMO director, the VPs, and/or the CEO of my organization.

3) I closely managed the budget, especially on these three engagements (although it is my practice to do so anyway). I believe this allowed me to take early and successful corrective action. On two of these projects, the budget did start to become ‘unhealthy’ and I initiated discussions with the customer project sponsor to alert them of the fact. It wasn’t the same as openly discussing it as a status item during the weekly customer call, but it was helpful….albeit awkward.

Summary

The takeaway is this: the budget is everyone’s business. Do what you can as the project manager to discuss the project budget up front at kickoff time and let everyone know that you intend to openly manage it and discuss it with the customer on a weekly basis. If you get pushback, then stress its importance while trying to understand the reasoning for the pushback. Educating everyone on tight project financial management may get you over the hump with the customer.

About the Author:
Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

Know anyone who falls into one of these categories?? Have a great weekend!

Though many businesses use project management software, a common sentiment exists that successful project managers often achieve results in spite of their software tools, rather than because of them. Others believe that project management software is not particularly effective at boosting productivity, citing the large amounts of money spent every year on software that quickly begins to gather dust on some forgotten shelf. In fact, there is well known dispute as to “what exactly is project management software?”

These individuals (whoever they may be) are only partially correct. Project management software, like any tool, must be used effectively by the user. A hammer, regardless of the quality, will not drive a nail by itself. Further, some project management tools are vastly superior to others, either because they are streamlined for a PM job or simply allow for a greater range of processes and data collection. Now let’s be clear, I have always said, “A fool with a tool, is still just a fool.” And on a more positive note, there are extremely successful PMs I know who have managed projects using Microsoft Excel®.

The important thing to remember here is that, for a project manager, something like 80% of the job is communication. For this reason, the primary functionality a project manager looks for in his or her software is seamless integration of data to facilitate rapid feedback and response – or more succinctly, they need timely and accurate information. A manager who can quickly identify if a project is running as scheduled or if an employee is keeping up with necessary and assigned tasks will have the strong advantage of adapting to issues as they arise (and we all know that “Murphy” visits all projects!). Speed and accuracy of information is critical to maintaining this advantage.

Another problem area is when project management software applications go too far in making predictions, suggestions or presenting a myriad of unnecessary options and thereby creating a unique set of problems. Though these suggestions may be valid and the options may provide much more flexibility, it can often result in the project manager becoming at best, confused and at worst, completely sidetracked in the software, even losing sight of the original project requirements. Again, effective project management software will provide the tools for data collection, analysis and distribution. It will not attempt to take over those tasks completely or make “guesses” as to the best course of action where human input is critical. If the software was that good – we would not need to train project managers – right?

Another issue that arises in the use of project management software is the ambiguity of the information presented. For example, even if the software presents the seemingly simple prediction that a project will take 100 hours to complete, difficulties can arise in the interpretation of this information. A novice project manager might be unable to see the other aspects of this task and the issues that might arise. Will these 100 hours be spread over a period of days? Weeks? Longer? And further, how will the human element of the team affect this estimate? Every time an employee takes time off, calls in sick, or falls behind in their assigned task, this estimate will need to be altered. Project management software that is powerful enough to account for delays by tracking these human elements and showing remaining work or effort can greatly increase the effectiveness of a project manager’s resource and schedule management, regardless of skill level.

The lack of software integration is yet another difficulty that can frustrate even the most skilled and efficient project manager. Regardless of the proficiency of individual software applications at completing a given task, failure to integrate with common or existing data from organizational systems can create a nightmare scenario in which the data compiled in a project management program cannot be done in real time. It is not enough for software to allow for the option of integrating with other well-known programs, it must do so well, and with the expectation that the data collected in that program will be used in other capacities.

Project managers that encounter software that allows for the honest, useful, and seamless collection and integration of information will find they have a powerful tool that allows them to accurately predict and produce results with regularity. While software should not be expected to replace effective management or decision making, it can insure that time is being spent in an optimally efficient manner.

And time, after all, is money.

About the Author:
Bruce McGraw is Sr PM, Technologist, and the COO of Cognitive Technologies, a woman-owned consulting firm specializing in project management, collaborative processes, and organizational effectiveness. Bruce has the privilege of overseeing all technology and large-scale projects and the establishment of enterprise program management offices for client organizations. Bruce holds an MS in Technology Management from the University of Maryland's University College and a BS in Business Administration from the University of South Carolina. Bruce is a certified Project Management Professional (PMP) and is an active member of the Project Management Institute. He is also a certified Microsoft Technology Specialist and advises clients on harnessing the new technologies for improving organizational outcomes.

Most project managers have experienced an engagement when the customer was a little less than thrilled to be paying a high hourly rate for someone they considered to be somewhat ‘expendable.’ And if it hasn’t happened to you yet, it probably will at some point. Usually, customers are fairly well educated in the process of project management and understand the importance of having a trained and experienced project manager leading a group of skilled resources charged with implementing their solution. They understand that without proper oversight, chaos would likely ensue. But there are still those customers who see the project manager being billed out of a professional services organization at $150/hour or more and wonder what they’re really getting for their money.

The same can be said for internal projects and executive management. If you’re running internal projects in an organization, sooner or later you’re going to run into someone in senior leadership who doesn’t value project management. They may wonder why project management hours need to be hitting their budget for a software development effort or for implementation of a new e-commerce site. They just don’t see the value or the return on investment (ROI). All they see is money being spent.

As project managers, we’re often under the gun to show that we are adding value to the organization, to the project, for executive management, and/or for the customer. How do we do that? What ways can we show added value to the project beyond being a gatekeeper managing the daily tasks of our project team?

Here are a three ways that experienced project managers can add value to their organizations as well as projects they oversee:

Manage scope and implement change orders

Scope management is really the responsibility of everyone on the project – even the customer. Once requirements have been finalized, everyone should be adhering to them and not performing work that falls outside of those requirements. But it happens…through small add-ons, harmless customer requests, and grey area work. Those harmless hours can wreck a project budget if left unchecked.

This is where the experienced project manager can show extreme value. By carefully managing scope as well as deviations to the agreed-upon requirements, unplanned work can be turned into additional revenue for the delivery organization. This revenue could come in the form of change orders or well-documented functionality to the customer for revised requirements. Careful scope management is a win-win situation.

Push for the real solution

Many customers think they know what they need and what it will take to get there. The project manager and team that merely acts on the initial request may end up delivering a final solution that misses the mark in terms of necessary functionality for the customer’s real end users. It is critical that the project manager step in during the planning phase, ask the hard questions and guide his team down the path of figuring out the real issue or need. Often, the original need was merely a symptom of a deeper issue. Finding that real need adds extreme value to the project.

Scale the PM role as needed

As previously mentioned, not all customers value project management. Some see that role as unnecessary. I had one customer tell me at the beginning of the project that he didn’t like me. When my business analyst said, “you don’t even know Brad” the customer answered, “he’s a project manager and I don’t like project managers.’”

I sat down with the customer and found out that his real concern was that he had a limited budget and he was afraid that we were going to spend too much time on my management of the project. That was my cue to be sure I watched what I billed, sent only my developer on site while I managed remotely rather than charging the customer for my travel, and managed the project closely, keeping the customer very informed. I spent as little as I could, but did not give them less service than they needed. They quickly changed their attitude both toward me personally, and project managers in general. I added value (somewhat reversely) to their project by staying in the background when I wasn’t essential at a given moment.

About the Author:
Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

“The worldwide communications infrastructure has already started moving gradually and inexorably in the direction of ubiquitous broadband access and transport, an adoption that will completely revamp the meaning of what constitutes a telecommunications service.”

– The 2007 Telecom Industry Review, The Insight Research Corporation

The telecommunications industry is changing rapidly—as is the Internet—and they’re creating a mutual feedback loop. This feedback loop is virtuous if you’re a consumer of such services, but it’s terrifying if you’re a supplier in these industries.

Telecom is changing the Internet, and vice versa. Let’s begin by discussing the Internet’s effect on telecom.

Skype: Freeware Comes to the Telephone

The freeware model for software delivery is a proven method for quickly creating a large user base for your product. In the software space, WinZip and Journyx Timesheet are software products that quickly garnered huge market share due to their zero dollar entry prices. LinkedIn, Yahoo mail and Gmail have taken off in the SaaS space.

Similarly, Skype, an Internet-based PC-to-PC voice communications application, has proven that many users will accept inferior levels of call quality if it is free or extremely low priced. This discovery has irrevocably altered the market and is causing other voice communications firms, including some long established providers, to lower their prices.

Far more important than the commoditization price ‘race to the bottom’ that Skype started is the fact that they convince people to accept the PC as a voice terminal. The company has demonstrated that voice over the Internet, especially when combined with instant messaging and chat technologies, provides some advantages.

There is nothing particularly unique about Skype; any competitor could offer the same service. Its first mover advantage, however, resulted in a large established Skype community, which limits the likelihood of users switching to another service. This means that the race to the bottom will only quicken as new entrants such as Google (which now offers voice-enabled chat on its Gmail service) enter the market with similar free offerings.

A Private Investigator?

Read the rest of this article at SoftwareCEO

Estimation can be one of the most difficult parts of a project. Important questions must be asked in order to form the right figures and plans. How long will the project take? How many resources will it consume? Consultants may also ask the following question: What is the appropriate amount to bid on this project? These questions are not easy to answer at the outset when one generally has only a vague idea of what will be required throughout the project.

The good news is that there is a fairly simple way to improve project estimation and, consequently, the bidding process. Most people do not realize that the requirements creation process can lend insight into the length and scope of a project. Let me give you an example of how this method works and then explain how you can implement it within your own company.

The Story

Back in 1992, I was working for a consulting company named The Kernel Group (TKG). During this time, I was put in charge of porting Tivoli’s software from Sun’s Solaris operating system to IBM’s AIX operating system. The project was to be done under a fixed bid, and consequently, we at TKG knew that estimating the effort required to port the code was of paramount importance.

I looked at the code with a coworker of mine, and he came to the conclusion that if Tivoli didn't make the project hard for us in some unspecified way, we could port the million or so lines of code in about a weekend. I told him that he was nuts - that it would take at least a week, maybe even two. We jointly decided that we probably ought to call it three weeks just to be safe. We also decided, rather smugly, not to report our padding of the schedule to evil upper management.

As a result, evil upper management drastically expanded the project bid to $325,000, and my coworker and I thought that this was a ridiculously high price. We believed that we were gouging the customer and that they would never accept it.

Yet they did accept it, and once the project began, we proceeded to discover how truly terrible we as software engineers were at the task of project estimation. To make a long story short, the porting schedule expanded to exceed our original estimate and we consumed not only all of the $325,000, but a whole lot more on top of it.

The Formula

Read the rest of this article at The International Community of Project Managers

To certify or not to certify…that seems to be the question. Many job postings for project managers request or even require the project management professional (PMP) certification – the industry standard as offered through the Project Management Institute (PMI). But do organizations need it? Are PMs better for it? Does it guarantee PM or project success? Will our customers care? Is the certification cost to the organization for certifying existing project managers worth the investment? Will the ROI be there or be enough to justify the initial expense?

The certified PMO

A project management office (PMO) full of certified project managers sounds great, right? It sounds like your organization is cutting edge. It sounds like your organization will be bulletproof, ready to take on the project management world and overcome the usual 50+% project failure rate, right?

Not so fast. While a PMO full of PMP certified project managers might mean that everyone speaks the same PM language, it certainly is no guarantee of project success. It may help, or it may mean that you just spent a lot of money putting a ring in the pig’s snout.

Reasons to certify

Certainly there are several reasons to consider certification of your current project managers and requiring it of all incoming project managers. You may be focusing your new business on government contracting and those contracts may require the certification. That’s a very good reason.

You may want a common language and understanding among your project managers. That can be a very good reason if it’s used wisely. Yes, your customers will get a standard brand – returning customers will see the same thing on future projects no matter which project manager is assigned to run the engagement. Think of it like eating at a chain restaurant like Macaroni Grill vs. eating at a one-off place like Joe’s Italian Eatery. One will be consistent no matter what city you’re in. The other, well, you won’t find anything exactly like it again.

A final reason – and this may just be for show or vanity’s sake – is to be able to say you have a PMO full of certified PMs. That is a case-by-case call on what it’s worth to you. You aren’t doing it to acquire business so the monetary aspect may be of little or no consequence. It’s a want, not a need.

Cost of certification

The next thing to consider is the cost of certifying existing employees and hiring only PMPs going forward. This is a consideration in every case except something like the government contracting scenario where it’s absolutely necessary no matter the cost because it’s required for getting new business.

First, there’s the cost of testing. Currently the fee is $555 for non-members of PMI and $405 for PMI members. And if you’re going to require certification, you should probably buy memberships for the entire group. Let’s say you’ve got 15 PMs in your PMO. A one-year PMI membership is $129. That’s $1,935 in memberships. The tests will cost another $6,075 for a total of $8,010 if everyone passes, and then a recurring $1,935 each year to renew PMI memberships. Over the course of say, five years, that’s a total investment of $15,750, assuming your PMO does not grow in size during that five-year period.

New hires are another consideration. Since the requirements to take the exam and actually pass the test are not that high – essentially two solid years of PM experience and a 61% passing grade on the exam – it doesn’t mean you’re forced to hire the most experienced personnel. Given that, salaries aren’t likely to be any higher unless you’re looking for lots of experience AND a PMP certification.

Summary

The final decision to require certification is obviously up to each organization and may be based on business need or just pure want. The cost is not exorbitant to the corporation, but it is definitely a long-term investment that needs to be considered. However, since the requirements are low for taking and passing the exam, PMO directors and company executives must not be blind to the fact that PMP certification doesn’t guarantee PM or project success. Unless there is a true business case for the PMP certification need, experience and proven past PM success should always be the greater deciding factor when building a successful project management infrastructure.

About the Author:
Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

Enjoy your weekend!!

Aaron Smith, editor of Projects@Work, looks at Gartner’s new report on the state of the PPM market.

While most enterprise software markets receded during the global economic crisis, the project and portfolio management (PPM) market has shown “marked resilience,” according to Gartner’s “2011 MarketScope for PPM Applications” — formerly known as the "Magic Quadrant for IT Project and Portfolio Management.”

“Demand for PPM applications has not wavered, but, rather, increased exponentially during the past 10 years,” writes Gartner research analyst Daniel Stang in the report released June 13. “Deep maturity is making it increasingly difficult to distinguish between competing products on feature/function alone. For buyers, this means that many of the typical PPM features and functions you would require when selecting a PPM system for the first time are likely to be in many of the products you evaluate.”

Many points of differentiation remain, however, including “the speed of deployment, the cost of the system in relation to number of end users, the amount of complexity within the system, the integration bridges available to third-party systems and products, and the deployment options and corresponding pricing models available from the vendor.”

The MarketScope report evaluated 30 PPM vendors across a broad range of criteria, including: customer experience, product strategy, product functionality, business model, innovation, market understanding and market responsiveness. The report rated vendors on a scale from strong negative to strong positive.

Read the rest of Aaron's article here.

Resource management is just one of the many necessary evils of project management. Project managers plan out the project staffing based on the skill sets that are needed on the project as well as when particular resources are needed to work on the detailed tasks in the schedule. Making sure that your project is not over- or understaffed at any given time can definitely make a difference in how your project budget is performing.

But what about the unanticipated loss of a key project resource? You may have brought this issue up during risk identification, but it’s not something you’re managing the budget toward or planning your schedule around. When you find out you’re losing a key project resource, you have to react quickly – but how you react and the processes you go through to replace resources can ultimately have a big impact on your project budget.

Since budget management and cost overrun have been ongoing concerns on every project since the beginning of time, the project manager must be acutely aware of how new resources will be brought to the project should the need arise. The best way to keep the hours and costs in check when replacing project resources on the fly is to have a plan. Without a plan, too many hours will be spent getting a new resource up to speed, shadowing the outgoing resource (if that’s even an option), assimilating the new resource into the flow of meetings with the customer, and familiarizing them with the project team dynamics. Have a plan so that hours can be minimized, costs can be kept reasonably in check, and the customer won’t agonize over whether or not they’re going to feel an impact from the transition.

Centralize project materials

If a central database of all project materials and deliverables is already being maintained – preferably by the project manager – then you’ve already won part of the battle. When a new resource must be brought on to the project, a database will eliminate the need to search for, gather, and hand over all relevant project materials to the new guy. Just point them to the database. Before you ever transition responsibilities to them or introduce them to the customer, you will want them to be up to speed on the history of the project – and that database is the place to start. It should contain all status reports, project schedule iterations, the statement of work, project kickoff materials, change orders, meeting notes, and copies of all customer deliverables, at a minimum.

Strategize with the project team

While it’s important that the customer know something about the transition considering you’re replacing a key resource that they’ve been interacting with throughout the project, your money and time is best spent first getting that resource ready for the real work. Give the customer a quick introduction and briefing on what is to come and how the resource will be engaged on the project. But there’s no real need to spend too much effort putting that resource in front of the customer until it’s absolutely necessary and until that resource is absolutely ready.

For now, concern yourself and the team with meeting to discuss the project, the customer, current status, ongoing issues and how best to transition the new resource into the flow of the moving project. If the outgoing resource is available, a 1-2 week period of shadowing is often the best route to take. If that outgoing resource was fired or had to quickly move to another project, then that may not be possible and it will be up to the remaining team to ensure readiness.

Customer introduction

Finally, after a short period of study and meetings to familiarize the new resource with the project, it’s time to formally introduce them to the customer and let them begin leading the tasks and customer discussions that were previously handled by the outgoing resource. Remember, even though the project budget is important and you’re trying to perform the transition as efficiently as possible, customer satisfaction is always a concern. If the customer senses there will be bumps from this resource change, their satisfaction level will dip and you’ll have damage control to worry about. All of this takes hours and precious budget dollars so be sure the resource has the skill set and is ready to engage with the customer.

Final thoughts

It’s never easy to change resources in mid-stream, but by making it part of your risk assessment and planning, you’ll know you have a plan. Thus, you can ensure that you’ll be following the most effective and efficient process to get the resource up to speed and customer-ready if the need should arise. Our team members are critical to our project’s success and without a plan, the team will spend unnecessary and unplanned hours making what should otherwise be a fairly orchestrated move.

About the Author:

Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

Project managers, or PM’s, are charged with the planning, execution, and completion of many projects from information technology to construction. Every industry needs project managers, and becoming one often involves a college education and one or more certifications. Because future and current project managers can have loads of questions, little time, and few experienced others to turn to discreetly, the internet often becomes a resource for PM’s.

To help you in your quest for faster, better answers, we have gathered 25 Q \& A sites about project management. They can help everyone from first year students with basic questions to experienced project managers under the gun to complete projects and find answers.

Check out the full list here at Project Management Training and thanks to Andrea Contreras for the tip.

Many companies are aware that there are technologies available that offer a large payback in the long term. However, the implementations of these technologies can be very disruptive in the short term. Personally speaking, implementing a document management and/or workflow solution definitely has its challenges. Acceptance can often be difficult, from engaging management all the way through to the perception of the end user.

Here are a few tips that will help ease the transition and make the process from the point of discovery to the go live date far less painful.

1. The most critical point is people. Using the correct people in the correct roles is crucial to success. Unfortunately, many companies assume that software implementations should be managed or sponsored by the IT department -- not generally so. A better way to approach this is to engage the people from the department that will benefit most. For example, in accounting, the accounting manager can engage the people in the accounting department directly for necessary input. When a project affects a specific group of people, it is typically more successful if those people take ownership from the very beginning. Also, the project will be driven by business and department goals rather than from an IT goal perspective.

The role of Sponsors:

A. Keeps the project aligned with department/business goals.
B. Keeps an open line of communication between the implementation team and stakeholders, as well as being a ‘cheerleader’ to the benefits of the implementation.
C. Works to gain and maintain the backing of their immediate department employees.
D. Ensures the proper people are in place to maintain the software, i.e. power users, certain IT people.

2. Talk about the new software often. Keep everyone in the ‘know’ of the benefits of the project. When speaking with end users, talk up the benefits of how the software will assist their work. When speaking with managers, talk up the dollar amounts saved or other business goals achieved.

3. Train your employees! When you change an employee’s environment or process, you must adequately train the employee or have sufficient documentation for the employee to be able to look up things they need to know. If an employee is not fully trained, their performance will lack, frustration will increase and the project will suffer.

4. Acknowledge the importance of change management! Of course we all know there will be those employees that will never buy into the new implementation. It is CRITICAL to identify these people early. Determine if these employees have loyal listeners. Address the ‘problem’ employee directly, but professionally, and have an open and frank discussion. Ask why they have issues with the project and address those concerns. Point out the early wins as well as the ways the software is working for other employees who have bought in. Pay attention to those employees who get excited about the project and announce their successes with the software in a meaningful way.

Acknowledge your employees’ feelings. Maybe those feelings are fear of change, fear of new technology, fear of looking foolish or stupid in new environment. Employees can be resistant to change, whether out of fear or an unknown expectation. The two key ideas here are:

1) How do employees perceive the change? Do they perceive the change as good or bad, (and why?)
2) Do they feel equipped to deal with the change?

By addressing these two issues, you begin to address employee resistance.

The idea of ‘talking up’ the new software discussed earlier is important here. When the end-users have an idea of what the change is and how it will improve their work/workload, you begin to take the edge off their fear. There are no surprises, no last minute changes to their work environment and hopefully, the sponsor has successfully promoted the benefits of the new system.

By engaging the employees during the process, they become a part of the implementation. They hear about the changes, see the changes and become a part of the changes. Their input is critical to their level of acceptance of the change. By getting their input and feedback, you are letting end-users know that their knowledge is important to the success of this project and to the company as a whole.

About the Author:

Denise Blackford is an Implementation Specialist and Corporate Trainer at iDatix Corporation, a document management and workflow processing company.

Questions, Polls and PMI

This morning, I presented a seminar entitled, Listen with a Poll – How well do you know your audience?

So, when I logged into facebook this afternoon and saw that the Project Management Institute (PMI) Facebook page had 5 NEW polls posted, I was excited to watch the responses roll in.

You can check out the polls on this page: http://www.facebook.com/PMInstitute

PMI is definitely interested in knowing your opinions on the relationship between social media and project management, among other things. To take their polls, you'll use the new Facebook Question tool just released in March 2011.

One thing that makes this Question tool GREAT is that you don’t have to LIKE the page to participate in the poll. If PMI had asked the same question using the simple status update, only people who like the page can respond. By using the Question tool on FB, anyone on FB can respond to the poll. Here’s how it works: PMI has more than 5,000 people who LIKE the page. So, all 6 of the Polls will show up in the home feeds of those 5000+ people. After 2 hours, 50-100 people responded to each of the 6 poll questions. The poll question was then fed to the Home feeds of those people, expanding the reach exponentially. It was displayed to the friends of each person who answered. This is a powerful viral communication tool, don’t you agree?

As you think about your own projects and business objectives, what information do you need to successfully complete your current project? Do you need feedback from a particular industry, a specific target market or your stakeholders? What question could you ask that would generate the answers? What pages are your “people” spending time on? If you are the Facebook page admin, you might consider using the new Facebook question tool.

You can learn more about it here: http://www.facebook.com/questions/

In the meantime, if you have questions about Questions (Facebook questions that is!) feel free to post them as comments here or contact me via email at michelle@daystarnewmedia.com. If you are interested in taking the Advanced Social Media Seminar: Listen with a Poll, please subscribe to my email newsletter to receive the webinar training calendar and GREAT weekly tips on using social media to achieve business objectives.

About the Author:

Michelle Cullison, consultant and professional speaker, equips businesses and organizations to expand from website to web presence to achieve REAL business objectives. Learn more about her company at DaystarNewMedia.com. Connect with Michelle on LinkedIn.com/in/michellecullison or send an email to michelle@daystarnewmedia.com.

It’s everybody’s dream, right? Bring in a project, product, or other large work task on budget and make a positive impact on the overall company bottom line. Too often, we as project managers must repeatedly apologize for our projects because the budget ran over and we seemed to have no control over it. Optimism abounds at the outset, but by the end of the engagement the budget has usually been sucked dry and we’re left wondering how and why.

There are four key strategies that I follow on my projects to help ensure that project budgets don’t get out of hand to the point of failure, that team members help me maintain profitability on the project, and that the customer remains satisfied while at the same time often paying more than the originally agreed upon price for the engagement.

These four strategies are:

• Forecast the budget with your project team on a weekly basis
• Add resources in a timely fashion
• Be financially accountable to senior management
• Don’t be afraid to initiate change orders

Let’s look at each of these in more detail…

Forecast the budget with your project team on a weekly basis. It’s important for the project manager to stay on top of the budget at all times. Too many times we set up a budget and then only review it periodically or worse…almost not at all. Then one day we wake up to find that our project is 50% over budget and it’s far too late to take any corrective action and any hope of bringing a profitable project into the winner’s circle is completely gone. Failure. Don’t let this happen to you….ever again.

Your team is not only smart and skilled, they are also the biggest spender of your project budget. Often your resources are hitting the project budget at $150 or $200 for every hour they spend on it. Make them part of the budget oversight process. Why? Because we’ve all been at that point where we’re sitting at our desk on a Friday afternoon trying to remember where we spent that last five hours of our 50-hour week as we fill out our timesheets, right? I can tell you from experience that if your project resources are working on multiple projects, then whatever project that has the least budget oversight is going to get those ‘grey hours’ charged against it. Don’t let that be your project! If you save three hours per week at $200/hour on a year-long project, that’s $31,200 of ‘grey hours’ you saved – and that’s probably just from a single resource!

Add resources in a timely fashion. We rarely start our projects with the full team assigned at the outset. We review the statement of work, plan out our project schedule in detail, and start assigning tasks. Then we fill out resource requests to staff our projects with the right skill sets. If this sounds like your scenario, then one thing you can do to help ensure greater project profitability is to onboard your resources only as they are needed. Idle expensive resources are going to cost your project money because they’ll find something to do on the project. If each of your assigned resources is striving for 100% utilization, I guarantee you they won’t be sitting around for free. Ask for the resources you need, but only ask for them when you need them and look for times to remove them from your project when they are going to be idle for an extended period of time.

Be financially accountable to senior management. One of the best ways to force yourself to closely manage the project financials is to make yourself accountable to your senior management. Include detailed project budget status information on your weekly project status reports and distribute these reports to your senior management on a regular basis – even if no other project managers are doing it. It will serve two key purposes: you won’t be able to hide your head in the sand if the budget is in trouble AND, as an added bonus, it will make you and your project more visible in the organization which may come in handy later on if issues arise that you need assistance with.

Don’t be afraid to initiate change orders. Finally, NEVER be afraid to initiate change orders. Watch project scope carefully and revisit requirements frequently. If work is being requested that does not fit properly within the scope you agreed to with the customer, then it should not be started without a change order in place. It will only cause you pain and suffering in the end as your budget can quickly spiral out of control from this unplanned work.

If it’s work that your customer wants and needs, they’ll be happy to pay for it. I was leading a long-term software implementation project where my customer’s satisfaction remained very high even though I added over $100,000 in change orders within a four-month period. I presented them with well-documented change orders and the customer understood clearly that the work was not part of the original requirements but it definitely added significant value to the project. Well-documented and timely produced change orders can actually make the customer happy and increase the profitability of the project.

About the Author:

Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

Today’s guest post comes from Bruce McGraw of Cognitive Technologies. You can read more from Bruce at his blog, Fear No Project.

Despite the seemingly simple definition of the project manager as, well, the person in charge of managing the project, there are often many questions as to what specifically the role of the project manager should be. It is more than a title (See Job Title Inflation post). Since his team members are not employees or even necessarily subordinates outside of the context of a particular project, the project manager must be precise when defining his role and exerting influence, yet this role is truly more of a generalist.

In general, the job of the project manager is to know the schedule, scope and success criteria of the project, that is, the work that needs to be done and when certain requirements need to be met. He is further expected to enforce that schedule and the assignments to get it done (and be a good communicator). These are the bare-bones components of the role, but the methods used to achieve results in the project through team inspiration and management are largely individual. The project manager role might be defined as one that is quite flexible, but somewhat defined by ideas like the PMI PMBOK. The project manager will also be called upon to review project and time-management tools as well as deal with employee issues such as dishonesty, under-achievement, or poor estimation (Don’t get me started on all the things a PM is asked to do!).

First and foremost, the project manager must be an effective communicator. The vast majority of his or her time will be spent asking questions of their project team and confirming whether or not the project is running as scheduled to their superiors or external executive clients. They must communicate not merely to inspire but to ensure that the data collected by project management tools and the information gleaned from conversing with team members is both accurate and timely. Since the project manager is in charge of scheduling and communication, failure to use this information in ways that will allow the team to meet deadlines will reflect poorly on them and can create professional issues later on. This is why good PMs are always after the right information.

Another necessary function of the project manager is to determine the feasibility of a given project and plan the schedule. During initial negotiations with a client or superior it can be easy to fall into the trap of an unreasonable schedule with an impossible deadline. (This happens a lot when organizations do this step before they actually assign a PM to the project) This can result in frustration from both the project manager’s team, who will be negatively influenced by their failure to achieve their goal in the allotted time, and from the client or manager who made the request. It is far better to determine an achievable schedule that will satisfy all parties from the outset, rather than try to impress with a deadline that will inevitably be missed or pushed back. A project manager should also avoid projects with murky end points. A project will have a higher chance of success when it is defined with a concrete beginning and end as well as defined scope.

The project manager must keep a good record of all ideas he has pertaining to the project. Assuming that memory or hastily scrawled and illegible notes will allow for the recollection of important ideas later on is foolhardy. As the leader of their team, a project manager has the unique ability to access all of the information related to a given project. Therefore it is likely that their ideas will be beneficial in achieving the goals of the project, given the breadth of data available to them. Neglecting the project manager’s ideas on project implementation and execution is akin to squandering an important resource, and could potentially sidetrack or even derail the project. (I am assuming that the PM is trained and experienced in project management!)

Finally, the project manager should be professional. While there are many variations on the definition of what it means to be professional, one that applies well to a project manager is “to act in an honest and accurate way.” The project manager that maintains professional courtesy without letting his ego get in the way will have the respect of everyone working on the project and from his superiors as well. That goes a long way in determining how effectively a project manager has adapted to his role. By acting professionally and keeping in mind that the three most important things in project management are the schedule, resources, and communication, a project manager will be successful in a variety of projects and situations. Another aspect of professional is that they have been trained and have practiced the basic elements of good project management. If someone wants to be a project manager and is thinking about changing jobs, they should get training and do apprentice work with a good PM before stepping into a full project.

About the Author:
Bruce A. McGraw is the COO of Cognitive Technologies, a woman-owned consulting firm specializing in project management, collaborative processes, and organizational effectiveness. Mr. McGraw manages Consulting Operations, overseeing all technology and large-scale projects, including PMOs and the establishment of enterprise program management offices for managing major development initiatives. Mr. McGraw holds an MS in Technology Management from the University of Maryland's University College and a BS in Business Administration from the University of South Carolina. Mr. McGraw is a certified Project Management Professional (PMP) and is an active member of the Project Management Institute. He authors a Blog on Project management at http://fearnoproject.com.

The following excerpt is taken from Garry Booker's article at Projects@Work. Read the full article here.

Agile software projects benefit from incremental planning and frequent delivery of potentially shippable results. These benefits don’t apply to all projects, but slicing any project into short iterations is still a great idea. My current project is a nice example. I'm managing a project to purchase and modify two very large aircraft. It’s not a software development project, and there is nothing “potentially shippable” about our aircraft at the end of each two-week iteration. Also, there really is no need for iterative planning because the entire scope of the project has been known since the start of the project.

Nevertheless, we decided to slice this project into biweekly iterations, as many Agile projects do. Why? For a traditional project like this, what’s the value of organizing the project into short iterations? That’s easy: There is great benefit in shining a light, in frequent intervals, on the progress we are making (and not making). Every two weeks, we hold a very brief status meeting for the project team. Of course, the Agile community didn’t invent project status meetings, but Agile has popularized the idea that team communication can be facilitated by short frequent updates of progress.

In a traditional project environment, project review meetings might be conducted monthly, and the timing of these meetings might be driven by the availability of cost data, which can be days or weeks after the end of the month. This is not the case in my traditional project. Like an Agile project, our biweekly meetings focus on progress, not cost. So these meetings are not scheduled according to the accounting calendar; they are conducted immediately after each biweekly iteration.

The primary audience for a traditional project review meeting is often the company’s executives (who have a vested interest in cost). Traditional project review meetings may last for hours and may review multiple projects across the organization. Our biweekly project reviews are primarily for team member communication (although executives also benefit from attending). Our meetings are not merged with reviews of other projects. They are intentionally brief, but we have sufficient time to see the status of all relevant tasks, which is more than can be said for many traditional project reviews.

Read the full article here.

Make it a great weekend! See you back here on Monday!

In case you haven't seen it, Journyx CEO Curt Finch has a regular column over at Inc called Business Bytes.

Recently, he's been interviewing prominent business authors and consultants for his column. His latest interview series is with Adrian Slywotzky, author of The Art of Profitability and Profit Patterns. Mr. Slywotzky's new book, Demand: Creating What People Love Before They Know They Want It, will be out this fall.

Today's interview with Mr. Slywotzky is on Having a Magnetic Offer. You can read the full interview series here. Be sure and follow Curt's column for more interesting interviews!

A graduate from Harvard's Law and Business schools, Adrian Slywotzky is a sought after business consultant, speaker, and writer. Below, Adrian describes the qualities that make a business magnetic.

Curt: What does magnetism mean in the B2B world?

Adrian: Whenever I am speaking on the subject of magnetism, I always ask my audience, “Does the term magnetic apply to the B2B world?' Their answers are always fast and furious: “You bet it does!'

Something that's magnetic in B2B solves a cluster of problems. How much money does the offer save the B2B customer? How much does the solution improve the customer's economics? Is it a low risk decision? Is it a career-enhancing decision? And most importantly for buyers in big companies, does the product or offer help the customer to effectively navigate through the politics of the decision-making process in their company?

In the B2C world, the critical aspect of being magnetic is the emotional resonance that the product has with the customer. In the B2B world, being magnetic isn't just whether or not the solution radically improves the company's economics, either through lower capital, lower cost, or better sales. Rather, the critical aspect of being magnetic in the B2B world means it applies to the whole relationship, including the political side that often dominates B2B decision making.

Curt: Let's look at this from a real world point of view. My company sells software. How would a software product address the political structure of a company in order to enhance the chance of hitting a trigger point and becoming a magnetic product?

Adrian: It depends on whether it is a small or a large sale. If the software product is sold into an IT organization and is implemented in a relatively small part of the organization, it very much depends on the relationship with the purchasing decision maker or the head of the IT department. From their point of view, they see not only its functionality, but also the actual value it's providing to the company. They can report to their managers, “This product saves us money, is easy to install, and is not disruptive in our business.'

If it's a large-ticket software product that requires layers of approval, then there's a whole set of techniques that must be considered, such as having prototypes that work or the product being tested in the company to ensure it's trouble-free. That rounds out the other half of the equation. It's not just functional and it not only saves the customer money, but also it's easy to acquire and implement, and there is very low risk around it.

Curt: It sounds like magnetism is a mirror of the hassle map.

Adrian: It definitely mirrors hassle map. You can always draw a hassle map for the end consumer, but the hassle map for the B2B customer is bigger, more complex, and richer in problems to be solved. On top of this, of course, is a more complex purchasing process than is typical for a consumer. Being able to address not only the functionality, but also the purchasing process, will cause companies to be successful in the B2B world.

Curt: At my company, we sell time sheet software and our hassle map is long and extensive. To begin with, everybody hates timesheets!

Adrian: Correct, everybody.

Curt: Everybody! How do I fix that?

Adrian: The point of departure for this research on demand was Vernon Hill (the founder of Commerce Bank). He recognized that everybody hated his bank. Robin Chase recognized that everybody hated the hassles of car ownership and founded ZipCar. London-based Julian Metcalfe recognized that everybody hated the soggy sandwiches that they had to eat and co-created Pret a Manger.

The first thing to do is look around and see what exactly everybody hates and then turn that into a product that's ridiculously easy, painless and effortless to use. Almost nobody gets it right on the first try. Many great entrepreneurs have the right target in view, but then it still takes two or three years to go from good, to very good, to the kind of magnetic offer that makes the customer smile. At that point, in terms of economics and profitability, the customer can't stop talking about this wonderful, new product.

In fact, the answers to two simple questions can measure how magnetic an offer is relative to its competitors:

1. How many customers say I love this company or this product? The best ones score 80-90% where their rivals score 20-30%.
2. The second question is even more important: how many times in the last month have you talked about this product in a positive way to others?
I guarantee the answers will surprise you and will help you figure out how you stack up against your competitors.

As you can see from this interview, having a very good product is not enough. The product has to be magnetic to get a customer's attention. Stay tuned for the next installment of this interview series where Adrian describes what makes a customer actually buy your product rather than your competitor's.

Today's guest post comes from Bruce McGraw of Cognitive Technologies. You can read more from Bruce at his blog, Fear No Project.

Project management would be a delicate task even if there was no chance that unexpected issues could arise over the course of a project. Unfortunately, there is no such thing as a project that is free from problems of any kind. The best an effective project manager can do is to attempt to minimize the effect that these issues have on the outcome of a given project. Many times, actually most of the time, the issues that arise are related to the human aspect of a project, whether from the project team itself or from stakeholders who are external sources such as clients or outside experts.

Perhaps the biggest internal issue that can arise is dishonesty from one or more project team members. While most people are not trying to be dishonest, the lack of full disclosure or omission of information is not honest and accurate data. A project manager is expected to gather information from team members and consolidate that information with data from other tools to determine how far along a project is and whether individual team members are on schedule. Usually the project manager has no choice but to take the information given by his team at face value, and then use it as if it were fact. If a team member is dishonest (due to being behind schedule personally or some other cause), then the estimations made by the project manager can be rendered invalid, resulting in a sabotage of schedule and potential failure to meet a deadline.

Another possible issue comes from experts who feel that they are always correct. Though expert input is undoubtedly beneficial in many scenarios, having a headstrong expert either on the team or overseeing the project in some capacity can prove disastrous if he is unwilling to bend his opinion. This issue is exacerbated further if an individual feels he is superior in either intellect or skill to the project manager, resulting in a situation where team members feel torn between following the instructions of the project manager or bending to the intellectual force of the expert. The optimum tactic here relies on finding a common ground where the expert feels his input is suitably appreciated while the project leader maintains the ability to lead the team in the final decision. This is why we talk about collaborative teams being the highest performing.

When dealing with companies that want a project completed within a given timeframe, one of the best tools a project manager can use is past records of similar projects. This technique has long been included in the PMI body of knowledge for PMs. These historical records can tell the strategy of the approach to the completion of the project as well as how long that project took to finish. Unfortunately, estimation of this kind can be difficult when clients fail to keep a record of their past projects in sufficient detail or, conversely, when the historical data is too specific to be of use. While there is little a project manager can do to alleviate this issue during the course of a single project, encouraging the company to keep adequate records of completed projects will help in future interactions.

Another way in which company executives sabotage their own projects is through the constant bombardment of the project manager with the need for updates on the project. This can be a huge waste of time for the project manager who has to take time from overseeing his team to discuss unnecessary details with a superior. Of course, it is understandable that an executive would want updates on their project. Fortunately, this problem can be easily remedied if the project manager maintains a proactive approach to the executive and provides updates in a convenient and consistent way. Also, by demonstrating a record of adherence to project deadlines, the project manager can build trust with a company and thus alleviate the perceived need of an executive to unnecessarily check for updates. Fortunately there are many new tools on the market which, when implemented correctly, can help the PM provide regular and better information to the executives and stakeholders.

By attempting to identify these and other issues early on, a project manager can hope to avoid them or at least prepare for their ramifications. Any one of these problems is not as detrimental to the project as a project manager who fails to address them in an “expedient and effective” way. The successful project manager knows that problems will arise and is not overly phased by them when they do.

About the Author:
Bruce A. McGraw is the COO of Cognitive Technologies, a woman-owned consulting firm specializing in project management, collaborative processes, and organizational effectiveness. Mr. McGraw manages Consulting Operations, overseeing all technology and large-scale projects, including PMOs and the establishment of enterprise program management offices for managing major development initiatives. Mr. McGraw holds an MS in Technology Management from the University of Maryland's University College and a BS in Business Administration from the University of South Carolina. Mr. McGraw is a certified Project Management Professional (PMP) and is an active member of the Project Management Institute. He authors a Blog on Project management at http://fearnoproject.com.