Several weeks ago I attended the annual Project Management Symposium in Denver, sponsored by the local PMI chapter. It was a great symposium as usual.  It’s always energizing to attend a number of excellent programs on project management and leadership.

One of the featured workshops was by Rory Vaden on “Raising Your Performance to the Next Level”.  In this post, I would like to pass on some of presenter’s insights to you.

Rory emphasized that a common denominator of success is being disciplined, and he defined that as “forming the habit of doing things that we know we should do but don’t want to do”. I believe that this really is a common denominator of success, and I believe it is as important in project management as in any other area of business.

We sometimes speak of the “discipline” of project management, and it really does mean having the discipline to apply proven principles and best practices to the project. Many of the good PM practices take energy, focus, and discipline to apply. They’re often not easy to do, but if done well, they pay off in better project performance and higher likelihood of success.

Discipline makes a difference. And it applies to the organization and the teams, not just to project managers.

In the workshop, the presenter discussed discipline in terms of three major factors: focus, sacrifice, and action. He argued that all three are needed to apply discipline.

Focus is about focusing attention and our thoughts, words, and behaviors on something specific, such as a project management process (like project planning), project tasks at hand, or a PM best practice (like team building or developing a project charter). Focus is important because it concentrates energy and effect. Project leaders can help achieve focus by removing barriers in the team’s way or by motivating them by creating greater clarity about project goals or giving them a compelling vision about what it will mean to the business to achieve those goals.

Sacrifice is about the discipline to do what it takes, to do what is right for the long term of the project (or the organization) rather than what is easy in the short term. It is the “doing what we should do” that will make a difference even though it might be something we “don’t really want to do” because it challenges us in some way.

Action is about making things happen and demonstrating that you have the discipline to do what is needed. It means leading by example. It means thanking others on the team when they step up to difficult tasks. And it means activating both yourself and others to do the tough stuff that will make the project successful. It means being persistent by continuing to do what needs to be done even when you run into one road block after another.

I thought this was interesting because, even though I believe in the need for discipline, you don’t often hear people speaking about it. More often you hear about this “silver bullet” or that simple solution.

One thing that the speaker did not mention which I think goes hand-in-hand with discipline is the need for continuous learning and the effort it takes. Yes, it takes focus and sacrifice and action – but applying a best practice or principle for project success is never as simple as doing one little thing. It takes attention and effort to learn the whats and whys that will really make the important difference.

Project Success Tip:  Take some time to think about project management as a discipline and about having the discipline to apply principles and practices that may not be easy but will make a difference. Be a bit tough on yourself in this self assessment and examine whether you really do have the needed discipline or whether you take the easy out. The result is that you will likely become more successful as a project manager if you are willing to take that next step of being more disciplined.

Today, for all projects that represent a significant investment of resources and organizational energy, and certainly for all projects that are important to the business strategically, the project manager must give executive management visibility into the project.

The old standard monthly status report does not really provide any true transparency into the project. It provides indicators and data but often not real meaning and insight into whether the project is healthy in every sense and on track to achieve its business goals. It’s like opening a small window and letting bits of information show through to the world outside the project. Transparency, on the other hand, is like having glass walls so that the true state of the project can be seen by the world.

Transparency into a critical, strategic project means giving meaningful yet concise information about the project, and especially answers to the questions that executives would ask if they came to the project manager’s door to find out how the project is “really doing”. Transparency means taking the initiative to give senior management the answers to those questions before they come to your door.

Giving senior management the information they need about a project requires balance. Executives want bottom-line information, not lots of details. But they need enough information to be able to judge the key success factors for the project:

• Are the business goals understood by the PM and the team?
• Does the team have a plan and is it a good, doable plan?
• Have critical risks been identified and are they being mitigated?
• Is the schedule realistic?
• Are resources been used/spent wisely?
• Is the team engaged and committed to a successful result?
• And, finally, does the project need more executive involvement or intervention?

I think the need for transparency is beginning to be better understood. But I don’t think there is a simple formula for exactly how to do it yet. It depends on the project, the culture, the players involved, and the maturity of the organization from a project management perspective.

The best suggestion I can give to PMs is to think about what senior management needs to know (such as the answers to the above questions) and try to give it to them concisely but meaningfully. And remember to let your personal touch and leadership skills show through in the process.

Project Success Tip: Take the initiative to give senior management information and insights into your project at least monthly and more often if project dynamics justify it.

Have you ever observed an organization that manages projects by heroics? There are a lot of high-tech firms, especially start-ups, that are at the “ad hoc” or lowest level of capability maturity – and it is not unusual to see them rely on management by heroics.

These firms have not established any significant degree of project planning or project control. They often have a fun-loving, “cowboy” style of operation. In the absence of project management, sooner or later the project that is developing the next great product requires someone on the development team to be the hero who brings the product to completion.

The company at that stage almost always rewards the hero, and in doing so, they are rewarding behavior that will not serve them well if they want to develop products in a predictable and reliable way. Senior management may know better, but usually at that point in their development as a company, they are reluctant to start putting best practices and repeatable processes in place.

However there always comes a time, usually once the first product has been released, that the smart CEO or development director will realize that it’s time to grow up a little bit.  If they want to have a manageable product plan – with any ability to plan and control a product release schedule – they must have agreed-to processes for managing the development and release of products in a repeatable way.

I’ve worked for software start-ups, both product companies and client engagement firms, and I’ve seen it several times. Start-ups often have very talented and creative people, and start-ups are almost always high-energy, fun environments. But companies must mature if they want to eventually succeed and grow.

Project management requires discipline – that is, it requires the team to subscribe to certain behaviors and follow certain rules. By doing so, the team as a whole, and management outside of the team, better understands the overall development process, what to expect from the team, roles and responsibilities, and so on.

Discipline can be seen as a loss of freedom, and that’s why there is reluctance to take the first step on the ladder to greater maturity as an organization. But discipline also brings its own sense of freedom because it is a move from raw energy and chaos to a level of control and predictability. When you have predictability, you can begin to invest more energy in collaboration and team performance as opposed to individual performance. And strong team performance always outweighs strong individual performance.

Heroics – when that means rescuing a project – is usually an indicator that there is a lack of process maturity and organizational maturity, at least to some degree. Maybe there is a project management process that is not fully developed in some aspect – such as risk management or monitoring and control. So project management, or certain aspects, may be lacking and need attention.

Project Success Tip — If you witness heroics and know that it saved the project, you also know that the process, or execution of the process, has room for improvement.

I thought I would briefly revisit roles and responsibilities and the RACI matrix today. In projects and processes, sometimes there may be questions or confusion about who is responsible for what. If work is not getting done and people are pointing fingers at each other, you definitely know that there is lack of clarity about responsibilities.

The tool most often used to help clarify responsibilities is the RACI matrix (or its variant the RASCI matrix). Down the left side of the matrix are activities, tasks, major decisions, or deliverables. (If used for deliverables, it would be lower-level deliverables that one or a few people would be responsible for, such as documents.) Across the top are the roles, such as Project Sponsor, Project Manager, Business Analyst, and so on. In the cells of the matrix are the codes for level of responsibility or involvement. The level of responsibility of the indicated role for the particular activity can be:

• R – Responsible for doing the activity or making the decision.
• A – Accountable for approving the action or decision and answerable for its result.
• AR – Both responsible and accountable.
• (S) – Supportive by providing resources or other support that helps an activity get done or a decision get made.
• C – Consulted before the final action is taken or decision is made. Input from the role is required.
• I – Informed after the action is taken or decision is made.
• Blank – None of the above – i.e., no responsibility or involvement.

Note that the above use of “accountable” is not the same as “being accountable”, in other words, for being accountable to do something as agreed to or planned. On a project team, you want to collectively develop a project plan and have all team members be clear about activities assigned to them and also be personally accountable for doing them, on schedule if possible. As I’ve said before, that is best done if the team members are committed to the plan — i.e., having expressed their commitment to the project manager or, better, to the team as a whole.

So the multiple meanings of “accountable” is one minor annoyance I have had with RACI in the past, and that must be “taken into account”.  :>)  But if you want to clarify responsibilities – about who prepares a particular document and who approves it – a RACI matrix can definitely help.

Project success tip:  The RACI Matrix is a tool that is helpful in clarifying responsibilities assigned to the different roles on project teams.

Glen Alleman is one of the project management experts who writes articles for Project Success Tips, and he is both a true PM expert and a prolific writer. He cranks out posts on his blog, Herding Cats, at a rate that is astonishing.

I strongly and sincerely believe that the best way to achieve project success is through understanding and practicing the project management principles. But you need to adhere to those principles that are most proven to lead to successful projects.

Principles are far more important, in my opinion, than techniques and tools. If you follow the principles, it gives you much greater freedom and flexibility to apply the principles through different techniques and certainly through different tools. In looking at the spectrum of project management and all that it entails, there are a large number of principles that truly make a difference in my experience.

But there are a smaller number that are central to successful project management. In one of his recent articles, Glen writes about his core 5 principles – and he refers to the 5 principles frequently in his writing – but he not only states the principles, for each one he also describes a “measure” to know if you’re practicing that principle in an effective and practical way.

I recommend that you read Project Management Principles Need to Have Units of Measure – it’s an excellent article and practicing the principles will help you achieve project success.

Part of the project manager’s job is to help the business understand the reality of what the project will take in terms of the time and cost to produce a particular result (i.e., scope and quality). Just like when you shop for a new car, you may think you want all the best features and top quality, but when you see the price tag, you (the customer) may decide that keeping cost below a certain limit is more important than having all those features. Therefore, you decide that less power and less luxury can suit you perfectly fine. You (the customer) adjust your requirements accordingly.

During the course of the project, the project manager must often make decisions based on achieving or maintaining the right balance of scope (what is to be created and its level of quality), the schedule (time), and the cost (resources). This must be done based on the information known to the project.

Base your decisions and actions as much as possible on agreed-to requirements and known facts. Beware of assumptions that may be wrong. Beware of generalizations about what is required. Beware of wishful thinking. Assumptions, generalizations, and wishful thinking are invitations for project failure – goals not met, schedules missed, and budget overruns.

The project manager and team must understand the scope (requirements), people and resources allocated to the project, the work required, and then develop a project plan that you collectively agree will work. Planning does require estimating and making projections, but the more that you know about any constraints on the project and about the requirements for what is to be produced, the better the planning will be.

The ideal project situation is when, during the initial planning stage, scope is well-defined and risks are low, thus leading to projections of time and cost that have a high probability of being right. (Risks by the way are any factors, known or unknown, that can impact the project.) The challenge, though, comes in the less-than-ideal cases when scope and associated risks are not well-defined at an early stage and require significant analysis or discovery.

These kinds of scope/risk problems occur especially when new technology is being used in product development, implementation, or both. Many other conditions, however – such as when the business itself is changing or when the project is high-risk by its nature – can cause difficulty in managing scope, risks, external dependencies, schedule, and cost.

Most projects do not have scope perfectly defined and understood.  Most projects, especially large projects, have substantial amounts of risk. So base the planning and decisions, throughout the course of the project, as much as possible on reality and facts. The probability of success goes up when you avoid false assumptions and guessing, and instead make the plans and decisions based on reliable information.

You’ve heard the term “business agility”, I’m sure. And I’m sure you have a general sense of what it means… responding to the pace of business change, being innovative and creative, responding to competition and other business challenges…

Well, as part of business agility, I’m one who believes that the need to be agile applies very much to business project management as well. In the recent series of articles that I published by Dr. Aaron Shenhar, he argued for the need for a “new adaptive framework” in project management, and he’s talking about the same thing. Hal Macomber is also talking about he same thing in his blog, Reforming Project Management and the work he does with Lean Project Consulting.

So, it’s time to stop associating agile with a particular method of software development and begin thinking about how to be more agile, responsive, and adaptive in our approach to managing projects. And I’m speaking of all types of projects, not just software development.

In my new ebook on principles of project success, which will be released soon, I write about many agile principles even though I had not starting using the “agile” label to describe those principles. But I recently came across a great article entitled “What is Agile, Really?” by Kent McDonald. In reading it, I realized that agile is now very applicable to project management generally – without resorting to the terminology and methods of Scrum. And, more than that, the agile PM principles I believe in strongly are very much aligned with the thinking of others, such as expressed in Kent’s article.

In his article, McDonald emphasizes seven principles:

• Collaborate
• Iterate
• Serve the Team
• Consider Context
• Practice Excellence
• Reflect and Adapt
• Deliver Value

Kent’s article is well written and makes some excellent points about how agile principles can and should be applied to project management today in order to be successful. In his article, he explains and expands on each of the seven principles. In the paragraphs that follow, I will give my interpretation of those same principles.

In my writings, I emphasize a number of similar principles but I often use different terms for them. For example, instead of “collaborate”, I may emphasize the importance of building “cohesive” teams. And when I expand on that concept, one aspect that I include is collaboration – i.e., the actions of project teams undertaking creative development tasks collectively rather than as individuals in order to capitalize on the synergy and creativity that comes from teams working in a cohesive way.

“Iterate” is about the need of the team to learn in the course of the project — and this can occur during both planning and execution. In fact, not accounting for the need to learn — during understanding the requirements of what is to be produced and during actual development of the product or solution — is a probable (and common) cause of project failure.

“Serve the Team” is all about the fact that the project manager must be the facilitator of the team rather than the manager. To be truly successful, the team must plan and execute the project, and the project manager must facilitate the project by facilitating the team.

“Consider Context” is about the fact that we can no longer talk about best practices that always work. Best practices must be taken in context because different techniques may be best in different situations, and practices/techniques must be adapted to the specific context.

“Practice Excellence” is all about producing business results that make a real difference by delivering real value to the business. The team that is focusing on delivering real business value – if they truly understand the goal and the purpose of the project – should not settle for mediocre (partial) results and instead, should be self-driven to deliver full results and maximum value.

“Reflect and Adapt” is about paying attention to what is working or not working and adapting appropriately. In lean or agile approaches, this often described in terms of “continuous improvement” througout the project. Lessons learned at the end of the project are too little, too late.

“Deliver Value” is very similar to Practice Excellence, and I tend to combine these two principles. But in agile methods, there is an important emphasis on 1) doing only those things in the project that really add value, and 2) doing the most important and valuable things first. In iterations of development, it often makes great sense to defer anything that produces less value to a later iteration or to a later release of the product. Related to this is the need for the team to fully understand the requirements of the business/customer organization and to agree on activities that are most important (i.e., valuable) throughout the course of the project.

Project success tip: Begin learning about agile or adaptive principles and how to apply them to your projects. Such principles are driven by the need to deliver successful projects by adapting to continuous business change.

Because continuous learning is more important than ever in our fast-paced world, I read information technology and project management publications as often as I can. When projects are demanding your time at nearly every moment, it can be hard to do — but you must make the time to break away from the pressure and take in some input from others.

Sometimes it can be educational or informative, but it just might give you a critical insight or idea when you need it the most. Sometimes it can be refreshing or motivational – just the thing to inspire you to tackle that project issue in a new way or perhaps, instead of tackling the problem the same way you did last time, to seek out ideas from your mentor, Phil, or to brainstorm the issue with the project team.

So it was a couple of weeks ago that I was reading Computerworld – well scanning actually – and I came across an interesting article on project management. (I’ve been reading Computerworld for more years than I like to admit, but it’s still a great publication.) The article was written by Paul Glen, a fairly regular contributor to Computerworld, and the title was “Projects and the Ungrounded Middle“.

My immediate thought was what the heck does he mean by “ungrounded middle”? And the introductory paragraphs were very different… instead of the usual business-like approach that we associate with project management, Paul wrote about the undertaking of projects in a poetic and almost romantic language.

But he made a point that I hadn’t thought about before… that projects often have an ungrounded middle when the realization that “the work to be done seems overwhelming, and the obstacles insurmountable.” He adds that “it is the emotional low point of any project.” Paul goes on to say:

“When discussing success factors for projects, I most often hear managers talk about beginnings and endings. They recognize the importance of clear vision at the outset and brutal focus at the end. But these are the rational structures underlying a successful project. Managers also need to pay attention to the emotional ones.”

This was a good article and worth taking the time to read. Paul argues that project managers should not ignore the emotions of the team during that ungrounded middle of the project. It can help just to acknowledge the project challenges and the emotions associated.

Here’s the project success tip you should take away: Teams need motivation and inspiration just like project managers do.

Back in December, Glen Alleman wrote a post on his Herding Cats blog about project management maturity. It was entitled “Knowing How Much a Project Costs is a Measure of PM Maturity”, and it was based on a conversation with a client about their IT projects. Some of Glen’s readers had also stated in previous comments that they did not track costs on IT projects, and Glen seemed surprised at the apparent commonality of the problem.

Let me begin by saying that I could not agree with Glen more. Not tracking project costs does demonstrate immaturity in project management. And I would say that not tracking costs is not only common, it is pervasive in IT organizations.

In my experience, IT typically estimates the non-labor costs, and approval of the project is based on those costs. Management of costs in PM-immature organizations is considered a responsibility of management – usually some IT director or the business sponsor – and not a responsibility of the project manager. Those organizations consider the labor of employees on the project to be sunk cost, so the labor costs are essentially ignored. That is, those IT people would have to be doing something anyway, so those costs are not estimated or tracked.

Interestingly, as soon as contract labor or the use of consultants is considered for a project, it is recognized as a project cost, and it is tracked. But again management of those costs is done by “management” – i.e., some director or VP – not the IT project manager.

Usually time tracking by IT staff is not implemented in PM-immature organizations until senior IT management finally realizes they don’t have a handle on how much IT labor is going into projects versus support. Time tracking is often implemented to help get a handle on resource capacity – especially support (of technology/systems) versus projects (generally as a category of work, not specifically).

Once time tracking is in place, senior managers may then recognize that they can have IT staff track time against specific projects. Usually the labor “demand” is first tracked in units of person-hours. When senior IT management sees that IT labor can be measured on projects, it will finally click that “that which can be measured can be managed” for their whole mix of IT projects. At that point, a PMO will typically be established (if it hasn’t already) with the instruction to track actual labor costs of every project and every support function.

But it is not until the IT organization begins to have project managers actually manage a budget of all costs, including the IT labor (and perhaps even non-IT labor) in dollars, that the organization begins moving toward higher maturity in its PM capability. The non-IT labor on projects, by the way, is the investment in the project through its active participation of business personnel in the project.

As a bottom-line take-away, I would certainly advise IT organizations to move toward project management maturity by managing all costs including labor costs. Managing costs improves the likelihood of project success. But, in reality, it seems that most IT organizations usually have to move through a learning curve (similar to the preceding sequence) to understand why they need to manage costs and do it at the project level. Once they have learned the need, they will usually shift the project cost management responsibility from departmental managers to the project managers. At that point, it suddenly makes sense.

Please feel free to give us your feedback about Project Success Tips. You can influence how we evolve.

Thanks! And, as I say in the newsletter – To your project success!