Tag: Requirements

The importance of tracking actual costs and resource usage in projects depends upon the project situation. For some projects, tracking actuals is unnecessary or is not worth the effort required. In other cases, however, tracking actual costs and resource usage is an essential aspect of the project control function. In such cases, a system must be put into place to support the tracking process, and the collection/recording of the potentially voluminous quantity of data requires strong organizational discipline. Why then is tracking actual costs and resource usage on a project ever worth the effort required to accomplish it?

Depending upon the project/business environment, one or more of the following three reasons may underlie the mandate to track actual costs and resource usage on a project: 

1. The financial accounting system and/or the managerial accounting system of the project organization may require the complete and accurate documentation of the ultimate actual cost of the project. This is especially true if the organization must report that actual cost to some outside organization(s), such as: 
   • The Internal Revenue Service to justify tax write-offs 
   • An external project customer to justify project fees
     In other cases, management of the project organization may simply want the
     capability to measure the cost of executing a strategic initiative or the profitability of a project performed for an outside customer.
2. Having knowledge of actuals-to-date is a requirement for effective cost control while the project is ongoing. When estimated project costs are budgeted by activity and actual costs are tracked by activity, the project manager has a powerful tool to support his/her efforts to control costs on the project. At any given point in the project, the actual cost of the activities completed-to-date can be compared against the budgeted cost of those activities, so that the cost variance from budget is known continuously. Corrective actions can then be taken to reduce any negative (i.e., over budget) variance. In addition, the budgeted costs (or revised estimated costs) for the remaining activities can be added to the actual cost of the completed activities to develop a new estimate of the total project cost at completion.
3. Tracking actuals allows the organization to build a historical database that will
   support budgeting and resource planning on future projects. Such a database is
   especially valuable if the organization performs many projects that are very similar to each other.

Tracking actual costs and resource usage is not necessary for every project or in every project environment. However, when good reasons exist for tracking actuals, the necessary technical and procedural steps must be implemented to ensure that the process is executed on an accurate and timely basis.

---

Thomas B. (Tom) Clark, Ph.D, is Co-founder and former Executive Vice President of Project Success Inc. Tom is heavily involved in the development and delivery of PSI’s courses. In addition to his work with PSI, he is Professor Emeritus of Management at Georgia State University. He also served the University as Chair of the Department of Management and as Interim Dean of the College of Business Administration. Previously, he was an Assistant Professor of Industrial and Systems Engineering at Georgia Tech.

Tom has provided project management consulting and training services for a variety of
business, government, and non-profit organizations. For more information contact [email protected] or visit www.projectsuccess.com.

In my previous blog entry, I mentioned the importance of managing perceptions. I also wrote that not doing so was the main cause of why only one project out of three was considered successful by major stakeholders, according to the Standish Group’s Chaos Report ¹.

So, if we have to manage perceptions, where and how should we start doing that? The Chaos Report gives us pretty good leads on that, so, I am still amazed to find in my project management workshops that not even one participant out of 100 knows about the Chaos Report, its contents and conclusions (based, by the way, on data and observations on thousands of projects).

The report identifies the involvement of end-users as number one in its top ten list of key project success factors. Yet many project managers and their sponsors still shy away from this obvious tip. On too many projects still, project managers meet, at the start of the project, some so-called representatives of these ultimate project customers to discuss rapidly THEIR operational requirements. They will not be in touch with end-users again until much later in the project, only to find a very uninformed, displeased, and distressed party in full “resistance-to-change” gear. There is then a lot of damage control to do to regain end-user trust and ensure that they will commit to materializing project benefits from the deliverables “imposed” on them.

End-users involvement must be more than that. Successful project managers have long realized that, in this changing world of ours, customers/end-users also change their mind along the way and must also understand that conditions in the project environment change for all sort of uncontrollable reasons. Both project managers and their ultimate customers must be ‘in sync’, preferably in a continuous manner, in order for the former to satisfy the latter.

Ensure with your sponsor that you get proper end-user representatives on board and keep them involved in your project as it evolves. I call that the Proximity Principle and its functioning is quite well explained by Scott Ambler in his landmark article: Agility for Executives ². Do that and you will automatically get high quality deliverables (and highly satisfied end-users perceiving the same deliverables as you), while keeping the risks of not meeting requirements as low as possible. Do this also with all other major stakeholders and you will effectively manage perceptions and deliver successful projects over and over again.

¹ www.projectsmart.co.uk/docs/chaos-report.pdf
² http://www.ddj.com/architect/184415034?cid=Ambysoft

And more often than not problems take longer to solve than you’d expect.

The sort of problems I’m speaking of is often seen in projects where new technology is commercialized or where the availability of a new service depends on the introduction of new technology. It’s the type of problem where an obstacle presents itself and progress on the entire project is affected. Many times the barrier threatens a core feature the sponsor is eager to see.

So what can we as project managers do to deal with these very ‘hard to resolve’ problems that invariably arise?

There are several ways to address problems that arise over the course of a project. Each problem has its own attributes and requires its own approach to solving. But there are some generic actions you can take. These center around the notion that projects require a team-based approach to problem solving and a project manager can facilitate team performance.

The first and foremost consideration is that the team solving the problem needs to be a ‘team’. This means there has to have been something else they’ve done together prior to addressing the ‘big’ problem. I tend to look for things to nurture teamwork prior to taking on more challenging issues.

We’re all aware of the traditional phases of the team including forming, storming, norming and performing. We know the project team will drift in and out of these stages, depending on the dynamics of the environment and situation. If team members have a precedent on what to do to resolve smaller matters, then alignment of the team to focus on the more serious issue will be easier and faster.

Essentially we want to ensure team dynamics will not delay starting the problem-solving process. We do this by facilitating the team through as many ‘cycles of learning’ together as possible, early in the project. Here the cycles of learning apply to how members settle into their roles, share information and relate to each other in a synergistic manner. If they’ve experienced it before then revisiting it again for another issue is easier and hopefully progressive.

Another proactive approach is to mitigate the risk of technical issues through risk analysis and assessment. Unproven technology and integration issues can be difficult to uncover as part of the risk management process. However, the development methodology (i.e. agile, waterfall, prototypying, etc) selected for the project can help. For example, prototyping specific aspects of the technology or its integration can provide very illuminating results early in a project life cycle. Often these foreshadow where development ‘challenges’ can be expected. Schedules and budgets can be adjusted much earlier.

In closing, while good risk management is a great tool to identify potential problems, building a team ready and able to solve problems quickly and effectively is essential to deal with the uncertainty of scheduling solutions to problems.

 

---

Mike Lecky is a consultant at The Manta Group, a management consulting company specializing in IT governance, Project and Portfolio Management, Service Management, Risk and Compliance. Mike has degrees from the University of Waterloo (BScEng), The University of Western Ontario (MBA) and the University of Liverpool (MScIT). He worked for 12 years in aerospace electronics and as a Project Engineer managed several general aviation and US Military contracts. He teaches project management online with the School of Applied Technology at Humber College. Now, with over 25 years experience, he is a PMP and an information security professional (CISSP) and has a broad range of program and technology implementation experiences in the high tech and service sectors. Mike can be reached at [email protected]

Editor’s Comments

It’s that time again in the PMO. The previous year has been reviewed at length and resolutions have been made for and by the PMO but, as Terry Doerscher suggests in Last of the 2008 New Year’s Resolutions, it’s time to take a look at what resolutions the PMO manager might make that would benefit the rest of the PMO team in the coming year.

The California Gold Rush caught the world’s attention in the middle of the 19th century. It made many rich but shattered the dreams of many more. From those dreams sprang the modern city of Roseville with a population today of more than 104,000 citizens. As Demien Entrekin points out in Former Gold Rush City Has Big Plans for the Future, the city now has over 180 IT projects underway in its project portfolio.

Blogger Andrew Miller talks about the problems in being brought in to run somebody else’s project after the contract has been signed. And David Barrett discusses the importance of that critical soft skill – effective communication. Visit our Forums and give us your views and tell us what you think about the PMP designation in our Poll Question.

We hope you enjoy this second 2008 posting of Project Times and please take the time to email us with your thoughts and suggestions.

I find it amusing that the two words, “Project Manager”, mean such different things to different executives. After all, with the staggering success and proliferation of the PMI’s PMP designation and the highly projectized workplace of today, arguably, it should be as clear as a description of most organizational roles out there.

Not so! One day I will do a proper write-up on this, but here are the initial thoughts. It seems that there are roughly three categories of perceptions, ranked as per the amount of responsibilities implied:

The Facilitator Project Manager is there to keep the project plan updated, to schedule meetings and take minutes, and to remind people that their deliverables are due.

The Taskmaster Project Manager is there to run the project on a day-to-day basis, to be the person-in-the-know when it comes to anything to do with the project, to make decisions within the limits of the project scope, and to escalate upstairs when necessary.

The Mover and Shaker Project Manager is there to make things happen and the project succeed, with whatever “moving and shaking” is required.

Of the three perceptions, only one, in my mind is accurate, and that is the second. The first is ridiculous yet widespread. The third requires further discussion.

As a consultant, I never take on an assignment without a full understanding of my client’s perception of my role. And, in my view, neither should any project manager, whether in a consulting capacity or full time employee, if personal well-being and the success of the project means anything.

How would you like to be seen and why? I’ll tell you where I stand in the next entry.

 

---

Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc., a management consulting company located in Mississauga , Canada . His 14-year professional career has been devoted to the field of Information Technology. Before starting Bizvortex, Ilya served as a Director of Application Development and Maintenance at Mytravel, Canada . Prior to that, he lead IT projects, designed business applications and managed complex system implementations in the travel, retail and transportation industries. Ilya can be reached at [email protected].