Author: Cynthia Low

Top 10 Leadership Qualities of a Project Manager

Written by Cynthia Low on May 16, 2012. Posted in Articles. 2 Comments on Top 10 Leadership Qualities of a Project Manager

What qualities are most important for a project manager to be an effective project leader? It’s a question often asked and one that makes us sit back and think. Over the past few years, the people at ESI International, a leader in project management training, have looked at what makes an effective project leader. They quizzed some highly-talented project leaders and compiled a running tally of their responses. Below are the top 10 qualities in rank order, according to their frequency listed.

Inspires a Shared Vision

An effective project leader is often described as having a vision of where to go and the ability to articulate it. Visionaries thrive on change and being able to draw new boundaries. It was once said that a leader is someone who “lifts us up, gives us a reason for being and gives the vision and spirit to change.” Visionary leaders enable people to feel they have a real stake in the project. They empower people to experience the vision on their own. According to Bennis “They offer people opportunities to create their own vision, to explore what the vision will mean to their jobs and lives, and to envision their future as part of the vision for the organization.” (Bennis, 1997)

A Good Communicator

The ability to communicate with people at all levels is almost always named as the second most important skill by project managers and team members. Project leadership calls for clear communication about goals, responsibility, performance, expectations and feedback.

There is a great deal of value placed on openness and directness. The project leader is also the team’s link to the larger organization. The leader must have the ability to effectively negotiate and use persuasion when necessary to ensure the success of the team and project. Through effective communication, project leaders support individual and team achievements by creating explicit guidelines for accomplishing results and for the career advancement of team members.

Integrity

One of the most important things a project leader must remember is that his or her actions, and not words, set the modus operandi for the team. Good leadership demands commitment to, and demonstration of, ethical practices. Creating standards for ethical behavior for oneself and living by these standards, as well as rewarding those who exemplify these practices, are responsibilities of project leaders. Leadership motivated by self-interest does not serve the well being of the team. Leadership based on integrity represents nothing less than a set of values others share, behavior consistent with values and dedication to honesty with self and team members. In other words the leader “walks the talk” and in the process earns trust.

Enthusiasm

Plain and simple, we don’t like leaders who are negative – they bring us down. We want leaders with enthusiasm, with a bounce in their step, with a can-do attitude. We want to believe that we are part of an invigorating journey – we want to feel alive. We tend to follow people with a can-do attitude, not those who give us 200 reasons why something can’t be done. Enthusiastic leaders are committed to their goals and express this commitment through optimism. Leadership emerges as someone expresses such confident commitment to a project that others want to share his or her optimistic expectations. Enthusiasm is contagious and effective leaders know it.

Empathy

What is the difference between empathy and sympathy? Although the words are similar, they are, in fact, mutually exclusive. According to Norman Paul, in sympathy the subject is principally absorbed in his or her own feelings as they are projected into the object and has little concern for the reality and validity of the object’s special experience. Empathy, on the other hand, presupposes the existence of the object as a separate individual, entitled to his or her own feelings, ideas and emotional history (Paul, 1970). As one student so eloquently put it, “It’s nice when a project leader acknowledges that we all have a life outside of work.”

Competence

Simply put, to enlist in another’s cause, we must believe that that person knows what he or she is doing. Leadership competence does not however necessarily refer to the project leader’s technical abilities in the core technology of the business. As project management continues to be recognized as a field in and of itself, project leaders will be chosen based on their ability to successfully lead others rather than on technical expertise, as in the past. Having a winning track record is the surest way to be considered competent. Expertise in leadership skills is another dimension in competence. The ability to challenge, inspire, enable, model and encourage must be demonstrated if leaders are to be seen as capable and competent.

Ability to Delegate Tasks

Trust is an essential element in the relationship of a project leader and his or her team. You demonstrate your trust in others through your actions – how much you check and control their work, how much you delegate and how much you allow people to participate. Individuals who are unable to trust other people often fail as leaders and forever remain little more that micro-managers, or end up doing all of the work themselves. As one project management student put it, “A good leader is a little lazy.” An interesting perspective!

Cool Under Pressure

In a perfect world, projects would be delivered on time, under budget and with no major problems or obstacles to overcome. But we don’t live in a perfect world – projects have problems. A leader with a hardy attitude will take these problems in stride. When leaders encounter a stressful event, they consider it interesting, they feel they can influence the outcome and they see it as an opportunity. “Out of the uncertainty and chaos of change, leaders rise up and articulate a new image of the future that pulls the project together.” (Bennis 1997) And remember – never let them see you sweat.

Team-Building Skills

A team builder can best be defined as a strong person who provides the substance that holds the team together in common purpose toward the right objective. In order for a team to progress from a group of strangers to a single cohesive unit, the leader must understand the process and dynamics required for this transformation. He or she must also know the appropriate leadership style to use during each stage of team development. The leader must also have an understanding of the different team players styles and how to capitalize on each at the proper time, for the problem at hand.

Problem Solving Skills

Although an effective leader is said to share problem-solving responsibilities with the team, we expect our project leaders to have excellent problem-solving skills themselves. They have a “fresh, creative response to here-and-now opportunities,” and not much concern with how others have performed them. (Kouzes 1987)

References:
Bennis, W., 1997. “Learning to Lead,” Addison-Wesley,MA.
Kouzes, J. M: “The Leadership Challenge,” Jossey-Bass Publishers, CA.
Norman: Parental Empathy. Parenthood, Little, Brown, NY.

Don’t forget to leave your comments below

Timothy R. Barry is a trainer and consultant for ESI International with more than 20 years of experience in project management. He has worked with over 40 major organizations worldwide .With over 20 years experience, ESI International is the world’s largest Project Management Training and Consulting provider. A comprehensive mix of project management, E-training, tailored corporate courses, consulting, assessment and mentoring means they are able to provide their clients with proven methods that enable them to achieve their goals. To put ESI International’s Project Management Solutions to work for your company, or for more information, call +44 (0)20 7915 5099 or visit the website at www.esi-intl.co.uk.

Successful Projects through Agile Project Management

Written by Cynthia Low on August 25, 2010. Posted in Articles. 3 Comments on Successful Projects through Agile Project Management

SuccessfulProjectsThrough1 Both traditional and agile project delivery embody similar principles and practices that aim to deliver measurable results. Traditional project delivery can be described as a “waterfall” approach, which presumes that the requirements, expectations, duration, activities and outcomes of projects can be predicted accurately and planned in a sequence before any actual development activity takes place.

In contrast with traditional project methods, agile methods emphasize the incremental delivery of working products or prototypes for client evaluation and optimization. While so-called “predictive” project management methods assume that the entire set of requirements and activities can be forecast at the beginning of the project, agile methods combine all the elements of product development, such as requirements, analysis, design, development and testing — in brief, regular iterations. Each iteration delivers a working product or prototype, and the response to that product or prototype serves as crucial input into the succeeding iterations.

Delivering “customer value” is a key aspect of agile project delivery. Agile project management is conducted through the collaboration of a small, co-located team that usually consists of the customer/end user, a project manager, a business analyst (or the role of business analysis) and specialist(s). Agile theory assumes that changes, improvements and additional features will be incorporated throughout the product development life cycle, and that change, rather than perceived as a failing of the process, is seen as an opportunity to improve the product and make it more fit for its use and business purpose.

Key Challenges for Implementation

The migration from traditional product development and project management methods to agile methods requires substantive changes in the manner in which certain functions, such as gathering user requirements, deriving a project schedule, engineering the product, managing the team and measuring progress, are performed. The variations between traditional and agile methodologies indicate that “organizations must rethink their goals and reconfigure their human, managerial, and technology components in order to successfully adopt agile methodologies” (Nerur et al., 75). Companies wishing to adopt agile development and project management frameworks must overcome the following key challenges:

Project Portfolio Management

Agile approaches are best suited for innovative, exploratory/experimental projects such as new software systems with requirements emerging as development proceeds or new product development efforts for a quick-moving marketplace like consumer electronics. Project portfolio management (PPM) is a criteria-based decision making model for allocating scarce organizational resources to the most critical programs and projects. Where traditional projects may be funded using a well-worn forecasting process, a company calendar (e.g., fiscal quarter or year), or project milestones, agile projects may have to be funded iteratively based upon their deliverables and changing requirements. Many organizations have difficulty managing a bifurcated project portfolio.

Organizational Structures and Cultures

Moving to an agile framework is also an exercise in cultural migration. Depending on the geographic location, the business (i.e., products and services delivered), and the organizational structures and culture, some firms will make the journey from traditional methods to agile methods in an enthusiastic and seamless fashion, others will display considerable resistance to the agile ideas, and yet others are simply a poor fit for these approaches. For example, highly regulated industries that require extensive bureaucracies, intricate processes or detailed documentation will probably lack tolerance for the lean, nimble, artifact-light approach that agile advocates. The challenges in migrating from a traditional environment to an agile environment involve resistance and objections that may occur at three levels:

Management Level

Executive and senior management commitment and support is critical for adopting agile. Key management concerns that must be addressed include:

Predictability. Traditional managers like to work within predictable environments that allow them to outline detailed requirements, plan a complete project, forecast the budget and manage resources. Agile keeps their focus on the delivery of value to the customer.

Extensive Time Commitment. Managers must be prepared to accept and sponsor the intensive level of collaboration and involvement that agile methods require. They may have to forgo written status reports in exchange for the daily stand-up meeting.

Resources Management. Instead of being task managers, they must be ready to trust their project teams to be self-directed and to tolerate a bit more resource risk as they discover which team members are prepared to take the leap to agile approaches.

Risk Management. Managers must prepare to accept the reality of project uncertainty, risk and cost and abstain from arbitrary schedules and budgets.

Metrics and Measurements. Managers have to accept that the traditional ideas of success and failure will be transformed in an agile environment. Success will not be measured by compliance to plan or strict change control, but by the outputs delivered by the project teams.

The Team Level

Teams that harbor misconceptions that agile teams don’t plan, can’t estimate, don’t document and can’t scale can be significant impediments to any agile migration. A central tenet of the agile movement is the requirement for highly skilled developers. Since agile teams are expected to be small, self-governing and self-regulated, there is a high expectation in regard to the personal attributes of team members. They should enjoy the special challenges of working in an agile environment, be prepared to forego personal recognition in favor of team accomplishment and enjoy working in a highly transparent environment in which their work products, creativity and diligence are visible to their teammates and customers.

The Stakeholder/Customer Level

The trepidations that customers and stakeholders express include the fear that scope will lurch out of control. They will lose the traditional signposts of progress on which they have come to rely, and estimates of time and cost will not be available to help them allocate budget and staff. They also convey unique concerns, such as the agile requirement for intense collaboration and constant availability, and its affect on their own workload. Sales and management teams may express concerns about “account management” as customer representatives are integrated into agile teams.

Project versus Project Leader Manager

The traditional project manager (PM) who manages the triple constraints (scope, time and resources) through the use of a project plan will need to change his/her approach to managing the agile team. The successful agile PM must migrate from management to leadership, from monitoring compliance to enabling self-direction, and from acting as a foreman to becoming a facilitator of creativity and innovation.

Distributed Resources and Virtual Teams

A key concern of organizations that wish to adopt agile is the question of dispersed and virtual teams in agile environments. Communication, collaboration and customer interaction are key tenets of agility and many of the agile methods require attendance at a daily session. Therefore, the ability to form and manage teams across multiple geographies and times zones through the use of video, collaboration tools or other virtual techniques is critical to the success of agile projects. Additionally, teams in which PMs and developers are working on many projects at once add to these concerns.

Adopting the Agile Project Management Framework

To adopt agile project management, companies must take an iterative (or an agile) approach to introduce the framework within their organizations. They must become familiar with agile frameworks, assess their current capabilities to adopt agile project management, develop and implement short-term and long-terms initiatives, and adopt the framework over a period of time.

Learn about Agile Project Management

Before launching the “transformation to agile” project, it is important for key executives, senior managers and project managers/leaders to learn about agile frameworks, the Agile Manifesto, and the lexicon that surrounds agile. Learning can be achieved by taking courses, by reading books and publications, and referring to web resources, such as the Agile Alliance and the Project Management Institute (PMI®). Just as agile is an iterative approach, learning should also be performed iteratively to reinforce the adoption of agile project management.

Assess Organizational Readiness

“Are we ready to execute an agile project?” is a question that can be answered by conducting “Strengths and Weaknesses” and “Organizational Readiness” assessments. The organization needs to identify and evaluate the various organizational forces in place that may help or hinder its transition to agile project management. Executives and senior managers need to determine:

Degree to which the organization values innovation and creativity over organizational stability
Degree to which the organization can make independent, product-related decisions without consulting other organizations
The organization’s willingness to work with uncertainty
The organization’s ability to allocate resources full time to one project rather than assign to multiple projects
The organization’s ability to understand and embrace multiple approaches to documenting and measuring project progress
Degree to which the organization is able to partner with their customers

Assess the Project Portfolio

As previously mentioned, agile approaches are best suited for innovative, “never-been-done” projects. They are not the best fit for repetitive, well-documented, low-variability, low-uncertainty, and production-style projects. Executives, senior managers, and project managers/leaders review the project portfolio and divide it into two discrete portfolios by determining which projects are best suited for agile project management and which are suited for traditional project management frameworks.

Assess Project Manager (PM) Readiness

“Are the PMs ready to execute agile projects?” is a question that can be answered by conducting a “Project Manager Readiness” assessment. Executives, business managers, and all project managers need to determine:

Degree to which the project manager focuses on the customer rather than on following standard project management procedures
Degree to which the project manager values innovation and practical processes over sticking with the plan
Degree to which the project manager is comfortable with an uncertain and changing environment
Project manager’s skill and commitment to sharing information as needed with all stakeholders
Project manager’s level of commitment to the team and the willingness to promote team collaboration
Project manager’s ability to motivate the team, delegate, and then get out of the way

Assess the Project Team Readiness

“Are the project teams ready to function within agile project management?” is a question that can be answered by conducting a “Team Readiness” assessment for each team member. Executives, business managers and the PMs need to determine:

Team members’ ability to make independent decisions
Team members’ commitment and capability to collaborate and work as a group
Degree to which the team members can communicate in person
Degree to which the stakeholder is willing and able to become a team member
Team members’ ability to problem solve and come up with new ideas
Team members’ knowledge and experience with the application area and the tools for creating the project result

Analyze Existing Product Development and Project Management Methodologies

The organization’s culture, structure and methodologies will determine the effort required to transition to agile project management. Therefore, it is important for executives, business managers and PMs to clearly understand:

Which existing processes, tools and templates for executing projects can be applied to the agile project management framework?
How will jettisoning certain processes and structure impact the business?
How much effort and investment in time and resources will be required to develop new tools, templates and processes?
Will the metrics and measurement techniques to determine project success (or failure) need to change?
Will reporting methods be different for agile versus traditional projects?
How will stakeholders and customers react to the change?
How will the existing culture and organizational structure be impacted by agile project management?

Organic Implementation: One Small Project and One Team

Once the company makes the decision to give agile project management a try, it is critical not to turn the implementation into a “big bang” project. Instead the company should select a small project from its “innovative projects portfolio” and build a team to execute the project. This will require assigning the right PM and the most experienced team members to the project. Once the team has been formed, it goes through formal training to learn about agile and led by the PM with the help of the project sponsor(s), executes the project in an iterative manner using agile methodologies.

The Future is Here

Although the agile movement was the “brain child” of the software development and IT world, it has grown and evolved over the past several years. There is no question that today agile project management can be, and has been, applied successfully to a broad range of projects. Users and stakeholders have benefited from the agile project management approach — one in which the end user and the project team are partnered in a collaborative effort focused on the project vision and the end result.

Don’t forget to leave your comments below

Nancy Nee, PMP, CBAP, CSM, Executive Director, Project Management & Business Analysis Programs, ESI International, is a recognized expert in Agile PM and SCRUM. She has almost two decades of PM and BA experience in the healthcare, information technology, financial services and energy industries. Visit http://www.esi-intl.com.

References

Highsmith, James A. Agile Project Management: Creating Innovative Products. Boston: Addison Wesley, 2004. Print.

“The Agile Manifesto.” www.agilemanifesto.org

Nerur, Sridhar, Radhakanta Mahapatra, and George Mangalaraj. “Challenges of Migrating to Agile Methodologies.” Communications of the ACM, Volume 48, no. 5 (2005): 75. Print.

Augustine, Sanjiv. Managing Agile Projects. Prentice Hall, 2005

Guide to the Business Analysis Body of Knowledge (BABOK®) v.2.0. International Institute of Business Analysis, 2009.

Nee, Nancy Y. “Ensuring Requirements Gathering Success in an Agile Environment.” ESI Horizons. July 2009. Web. 15 March 2010.

Reprinted with permission from ESI International.

How Do You Want Your Software; Good or Fast? Part 2.

Written by Cynthia Low on August 4, 2010. Posted in Articles. 3 Comments on How Do You Want Your Software; Good or Fast? Part 2.

In our last post we explored an example of how subtle messaging around “fast over good“ can back-fire within teams in the long run. Now let’s look at alternative messaging with a focus on quality.

Be Careful In Your Messaging!

And you need to be real in your messaging. Teams can smell it if you’re not being truthful or don’t believe in what you are saying.

In this trade-off you also need to be patient and consistent. Conventional software teams have been trading off quality for so long that they don’t necessarily see they’re doing it. Or if they are just beginning to tenuously focus on quality, one pressured comment in the wrong direction can quickly derail any gains they have made.

In my team example above, in order to turn around our focus, I interrupted the Scrum Planning session and reminded the team that their prime directive was to deliver as much high quality software as they could within each sprint, working as a tightly coupled, creative, and self-directed team. That quality was the paramount factor in every user story. That we wanted, no demanded, that they finish each story to the point of no remaining rework. To use a common agile expression, so that it was done-done-done!

This coaching reminder changed everything. They adjusted their sprint contents and goal accordingly, pushing off nearly 30% of the stories that they’d previously “committed” to.

I found myself, from that point forward, consistently reminding my teams of this commitment to quality as inherent to agile project success. I would also take time to explain that quality doesn’t necessarily result in work taking longer. Since their DNA was so wrapped in making the wrong trade-offs, after years of the wrong pressure, I found that for every ten conversations I had on our Scrum delivery focus, nine focused on quality and one on content delivery, timing or speed. When consistently taking this approach, I found that teams would begin to internalize the messaging and start behaving in a more balanced fashion.

Asking the Right Questions

To this day, I think this 9:1 ratio is right for most teams transitioning from traditional to agile methods. Instead of Product Owners or Project Managers or Leadership focusing so strenuously on Schedule or Cost or Scope, they should be focusing on Quality. Questions about quality should be asked daily, instead of these questions:

Are we on schedule? Are you done yet, are we done yet, are they done yet?
What’s your velocity? Can we increase it by 50% this sprint? Why can’t you deliver twice as many templates as estimated?
We’re behind schedule, what is everyone doing to make it up? Working this weekend I hope!
Are we working overtime to recover the schedule? Why can’t we make the time up in testing?
What, you want to do some cleanup of hacked code! What will that do to the schedule? Can’t we just wait?
Is that work on the Product Backlog? If not, we can’t do it. Or another variation…Is that on the Roadmap? etc.
We are committed to this date and delivering specific content…period! Aren’t you?
We don’t have time for architecture or backlog grooming in this sprint…we need to simply Get It Done!

Ask these questions:

Have we reserved time to plan for testing? We’re going to vet that plan across the team! Right?
Did you vet that feature with the customer? Is it what they were looking for? Oh, they want changes, more than we planned for. Well don’t let that influence our doing it right!
Did you deliver complete unit tests with the solution? Did they all pass? I’m glad. Now we just need to maintain them in future sprints so we have an effective safety net.
Did the team sit down during the design of the component and review / collaborate on it? Did we post those design decisions and notes on the Wiki?
I need to know, did you meet our done-ness criteria before I sign off on this story? Anything you wish you might have done, but didn’t?
Were there any refactoring opportunities as part of this story? What would that have cost us in time?
Did you test it thoroughly? Did you document your tests in some fashion – acceptance tests, test cases, etc?
Did we do a code review? Did we make all of the noted adjustments? Did we re-review the code, if appropriate?
Are we moving too quickly or chaotically? Do we need to slow down a bit and re-focus on our quality and craftsmanship?

Do you see the difference? How hard would it be for you to reframe your typical project or team inquiries in this fashion? What impact would it have on your teams?

Remember: Trust and Engage Your Testers!

There’s a partner on our teams that we often forget.. It’s the testers! Why do we traditionally discount them so quickly? I think a part of it has to do with the balance we’re discussing here. When we’re balancing towards speed, we don’t want to hear anything that might potentially slow us down. And testers, whether you know it or not, are all about slowing the train!

They find bugs. They constantly talk about up-front quality and baking it into the project rather than testing it in. They want to test thoroughly and document the results. They, gulp, want to get things right the first time.

So, if you are emphasizing quality within your teams, guess who becomes a wonderful partner in your efforts? Gulp again, your testers!

Instead of trying to marginalize or ignore their feedback, which I see far too often, encourage and demand their feedback. Realize that they want to get the project done as quickly as you do. They just want it to be done well. Ask them for strategies to holistically deliver a solid product. Speak to them about historical trends and what risks they perceive they will uncover in your current project.

Above all, don’t short-shrift their time needs. Give them the time to do a solid job and setup your project culture so that their feedback is listened to and applied.

We Can’t Have It All. But maybe we can get Good and Fast Enough

I’m of the mind today in my agile teams that I can get good software and I can get it sufficiently fast or fast enough. Teams certainly get the fast part of that equation, especially since our traditional approaches to software have beaten it into their conscious and subconscious so well over time.

The point is I think we need to, by default, slow things down a bit. But slowing down doesn’t necessarily imply non-competitiveness or becoming truly slow. It simply means that we’re balancing across good and fast and delivering things that are Good and Fast Enough. And fast enough implies a thoughtful balance between Cost, Time/Schedule and most importantly, Scope. One that accepts ongoing adjustments based on incremental progress towards a clear goal.

We also need to emphasize the commitment we (the business) have towards good to offset our historical bias towards fast. It’s the recognition of our DNA and the power of asking the right questions of key stakeholders that can lead us towards effectively balancing across four dimensions.

Having a nice meal and getting it quickly enough? Patty my waitress doesn’t think so any longer and perhaps neither should you…

Don’t forget to leave your comments below

Project Portfolio Management; an Evolving Journey to Interim Value Destinations

Written by Cynthia Low on July 21, 2010. Posted in Articles. 4 Comments on Project Portfolio Management; an Evolving Journey to Interim Value Destinations

PorfolioMGMTanEvolving2 Any journey worth taking has a destination as its end goal. From an organizational perspective, the destination is to fulfill enterprise value. Enterprise value can take different forms. For commercial entities, it’s typically profitability and for government organizations, it’s delivering services. For almost every organization, though, there exists not one single destination, but rather many interim points along a continuous journey.

To understand where the journey to enterprise value will take everyone in an organization, it helps to first start by asking, “How did we wind up on the road we’re on now?” The economy, first and foremost, caused the single largest departure from our defined path, and the organization as a whole found itself driving cautiously on a dangerous and unfamiliar road trying to find its way back to a smoother one. During this time, demands from throughout the organization were muted and, for the most part, we were able to meet them (often heroically) with limited resources. Now, as the economy begins to improve, the demands on various parts of the organization, such as the IT department, to create value have begun to resurge. Yet, the road is still treacherous and our resources are not growing apace with these demands.

The reality is that enterprise value is no longer a single destination out in the distance, but a series of stops – or checkpoints – along the journey to ensure that value is continuously being delivered. Generating this value has increased the need to innovate, which is at odds with the desire to manage resource growth amid concerns about the health of the global economy. In fact, many firms are inadvertently slowing down their journeys by only cautiously expanding resources at the expense of losing market share to less risk adverse competitors.

Should it then come as any surprise that we find ourselves stopping often along our value creation journey asking if we’re still on the right track and if we have the appropriate resources? This need to check our course and progress has caused organizations to change their goals from doing first things first to doing first things faster. Deciding what to do must include greater emphasis on when it will be done. Some of this emphasis has been fueled by stakeholders, whether they are shareholders or constituents, who insist ever more vehemently that value be demonstrated more frequently. This insistence is often borne from a general unease about our ability to create value during economic uncertainty and has resulted in an escalating need to communicate progress and demonstrate results – more commonly referred to as accountability and transparency. Given this backdrop, we need a reliable Global Positioning System (GPS) to keep our organizations on the value creation track, the discipline of portfolio management.

Portfolio management is well suited to keeping organizations on course, acting as an organizational GPS to help make sure that short and long-term goals are realistically balanced against limited resources. As a repeatable governance process that enables organizations to prioritize, select, manage and deliver on their initiatives, it can be introduced and then expanded upon as an organization’s maturity grows. To begin, the business processes that an organization uses to assess and make decisions must be evaluated to determine if or how they can be improved. In tandem with this process discussion, it is important to understand what type of investments the organization is most interested in starting with on their portfolio management journey. This analysis includes discussion on the information needed to evaluate investments as organizations review the metrics commonly used and consider new ones to make sound decisions. For most organizations, there will be a basic set of information that will center on strategy, risk, health, value, cost and constraints as well as metrics that are only appropriate for specific investment types.

Next, an organization needs to compile a list of its investments, which typically starts at a departmental level and is then expanded across the enterprise. With the list of investments that make up the portfolios and a consistent, understandable way to evaluate and prioritize them, an organization can be begin to determine what investments it has the capacity to fund.

This determination requires that budget and resource constraints are taken into account. The organization will need to know the availability of each, even if it is only at high level perspective to start with, and how they are currently utilized. Time is another constraint and the organization needs to understand how it plays a part in the investment’s lifecycle. When first getting started with portfolio management, time and budget constraints are typically looked at first. The investment evaluation metrics help an organization determine the most advantageous projects to fund. Naturally, some low priority investments will need to be funded for reasons that cannot be ignored such as meeting regulatory requirements.

Next, organizations need to determine if the resources are available to bring investments to fruition given budget and time constraints. At the outset, the resource evaluation may be conducted on a role basis, for human resources, in terms of supply and demand to gain a highlevel understanding where there may be shortfalls that could impact the investment portfolio.

Portfolio management enables visibility into investments that are under management, ensuring effective decisions. The goal of these decisions is to continuously deliver value through products or services that increase revenue or efficiency, or in the case of governmental or nonprofit concerns, improve citizen services or military capabilities. Underpinning all the products and services that make up an organization’s value destinations are the vehicles that get them there – projects. These projects underwrite all of an organization’s value investments, often multiple times throughout the investment’s lifecycle.

The term “project” is often thought of as the end goal, but it’s rarely that and it’s certainly not the investment itself. Rather, it is the essential delivery vehicle that every investment relies upon. A clear example is the lifecycle of an enterprise software application. The application is the investment and is likely to follow a lifecycle that starts with its inception as a proposal to obtain a certain capability. A funding decision will then be made that may result in the application being purchased or developed. A project will then be initiated to either acquire and install or develop the application. The project is completed once the application is up and running and the application then enters one of potentially many maintenance cycles. It may be some time before it’s deemed that the application should be upgraded or perhaps outsourced at which point another project begins. Once the application is upgraded or outsourced, this project endeavor is concluded, and once again, the application is maintained. The decisions for these types of projects will be made repeatedly, but at some juncture, the application will need to be retired.

PorfolioMGMTanEvolving1

Portfolio management is not only about investments that are designed, built, developed or implemented and then launched. It’s also about how all investments whether new or old are delivering value and how they’re being transformed to expand or accelerate that value throughout their lifecycles via the many projects that support them.

Knowing where we want to go on our value journeys doesn’t guarantee we will get there, but portfolio management will help us determine the most efficient route. To do so, organizations need to move from prioritizing and selecting to the processes of executing and adjusting. To explain, after funding decisions are made, investments must be managed to ensure that they stay on the right course to value destinations. This entails using metrics to assess the performance of portfolios and, if calculated consistently and objectively, the organization is able to use these metrics to conduct regular portfolio review meetings to determine if portfolio adjustments need to be made.

Inevitably our journeys will encounter obstacles that will require that we establish new destinations as we realize that value will not be obtained. Changing the intended destination is rarely an easy decision as a great deal of time and resources are likely to have been spent on it. However, if where we’re going is no longer desirable or, worse yet, taking us off a cliff, then aren’t we better off changing direction sooner rather than later? Portfolio management helps identify the signposts that make the course corrections or adjustments easier to understand across the organization and the decisions more intuitive. In addition, portfolio management can help an organization determine the best alternative routes, taking much of the anxiety out of setting off in a different direction. The end result is that portfolio management enables a continuous cycle to examine performance, reprioritize and select investments and projects as our goals change, as well as stop endeavors that no longer take us to our destinations.

This portfolio governance approach applied across the enterprise offers the visibility to all the portfolios of investments and projects that support them. Portfolios are dynamic and reflect the changing nature of the path an enterprise takes as it strives to deliver value. These dynamics require the introduction of optional value destinations or investment, and these new opportunities must be assessed alongside the progress of the existing destinations to determine which ones will deliver the greatest value most quickly. Consequently, the vehicles or projects that are the catalysts for these investments – and in turn, enterprise value – must also be assessed frequently and changed as necessary. This regular assessment ensures a continuous focus on improving the composition of the portfolio while generating enterprise value. Given our many evolving journeys, portfolio management supplies the crucial, iterative guidance that ensures that our prioritized and selected investments and projects are in sync and that we are progressing smoothly towards our many value destinations.

Don’t forget to leave your comments below

Maureen Clifford, principal product manager at Oracle, has worked in product management and marketing roles for enterprise investment portfolio management for ten years. She has focused on IT, public sector and commercial portfolio management, including development and marketing of products for application and project portfolio management. She currently focuses on product marketing efforts for Oracle’s Enterprise Project Portfolio Management Solutions.

We Are All Project Managers!

Written by Cynthia Low on July 21, 2010. Posted in Articles. 89 Comments on We Are All Project Managers!

If someone asked you if you were a project manager, you might look at your job title and respond, “No, I’m the CEO,” or even, “What’s a project manager, anyway?” According to Wikipedia, a project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development. [1]

Most likely, you didn’t think that you would spend hours planning projects, gathering resources, engaging teams, monitoring and assuring progress and reporting on results. But guess what? Whether you’re a procurement manager or CEO, in actuality, you’re probably a project manager and you don’t even know it. You are the “Accidental Project Manager.” Are you the person who does the following?

Organize the team or the process, because no one else does.
Manage multiple to-do lists.
Keep three or more deadlines a week in mind
Faithfully cross tasks off a list as they are accomplished.
Move sticky notes on your desk or dashboard like a wigiboard
Missed a deadline because of others not completing their tasks on time.
Been given the excuse of, “You didn’t tell us about that,” when you know you did.
Find yourself getting confused about which task relates to which project.

Now that you’ve been mildly disturbed by the self diagnosis of what may sound like a horribly tedious disease termed project management, you can be comforted by the fact that there are thousands of people going through the same experience and there’s a range of treatment options out there. Relief can be yours if you are willing to confront the challenge head on. Say it with me – I am (insert your name here), and I am an accidental project manager.

In all seriousness, the fact that there is an entire field of professionals and several organizations (i.e., PMI – Project Management Institute, among others) dedicated expressly to project management, provides the everyday accidental project manager with a treasure trove of best practices as well as a host of tools aimed at lighting the pathway to success for any initiative. Even if you only manage an occasional, short-term initiative, by taking your cues from the pros, you can anticipate obstacles and reap the benefits that come from formalizing your approach to project management. The bottom line – you can make it so that your projects get completed on time and under budget if you take the right approach, and in the end, this means accolades for you and more profit for your business.

What Accidental Project Managers Face

The first obstacle Accidental Project Managers face in achieving project success is finding a way to get everyone on the same page. Within an organization, roles are often highly distributed – that is, multiple people may have a small part in ensuring a particular task is completed. Equally often, a bottleneck in completing one task may hold up dozens of others working on the same project.

The need to be on the same page can also be evident internally when working across departmental lines, such as when the marketing team needs assistance from the technicians to implement a new Web initiative, or the manufacturing design team needs quick turnaround from the modeling production department. Forget for a moment about ensuring timely completion of tasks. Without the right mechanisms in place, it can be a struggle to even collect status updates from in other departments. For a project manager, even an accidental one, this can mean things grind to a halt quickly.

Those potential obstacles are functions of the mechanics and ability of the organization as a whole to adapt to dynamic factors, but equally challenging are those presented by the personalities present within organizations.

Another factor can be information hoarders – those who don’t share intelligence quickly or effectively. Sometimes, an individual’s working style is such that he or she prefers not to share news on progress as part of an effort to control the process or perception of performance. Sometimes there’s a belief that those in other departments will not understand details specific to another’s role in the project. Other times, priorities shifted by leaders aren’t communicated swiftly to those managing the day-to-day tasks of the business. Regardless of cause, instilling a culture where information is shared, not protected, is vital to project success.

Still another obstacle is the resistance to adoption of new processes. Often, this starts with the executive team, the group most likely to be set in their ways regarding planning. Sometimes, the idea of a structured, strategic approach to project planning sounds like a lot of hard work. Team members can get nervous about accountability, don’t want to switch from old-school paper methods, or are of the mind, “We’ve always done it this way.” The accidental project manager must convince these individuals that the time it will take to create and develop new methods and processes will be dwarfed by profits earned as a result of the efficiencies those new processes will bring.

Benefits of Formalizing Project Management

Why formalize your approach to project management? Think P5 – proper planning prevents poor performance. For most projects, the main measure of performance is project speed. Project speed leads to efficiency and greater profit.

First of all, well-organized, clearly depicted work schedules get you the chance to manage a project to begin with – by helping you win it! At project scoping and bid stages, contractors that present a calendar, Gantt chart or other visual tool that explicitly lays out the project schedule instill a greater sense of confidence in those making the decision of who to hire.

Once underway, faster completion of one portion of a project can often mean a contract bonus for the contractors involved. And projects finished on time more often lead to repeat work and more referrals.

Even if there are no direct monetary incentives for project speed, if deadlines and objectives are created through a collaborative process from the outset and good communication on status remains in place, fewer project revisions are necessary. As a result, the project managers, as well as staff and contractors, are spending less time in project-update meetings, freeing up their time to work on the actual task at hand.

Another primary benefit of formalized project management is that it instills greater accountability of each individual participating in an initiative. Team members realize their position within the workflow of a project and get a sense for how their performance impacts other tasks, deadlines and, ultimately, individuals. Formalization usually leads to status updates, spurring a more take-charge approach by each stakeholder who realizes that he or she is more accountable due to project transparency. Many times, team members feel more comfortable knowing precisely what is expected of them. The process of entering information into a more structured system both clarifies their responsibilities and reinforces the belief that their success will be recognized.

Measurability is another key advantage of formalized project management. Not only can team members track their progress against stated goals, but they can also improve ongoing estimations of project lifecycles. Some common metrics include:

The project is delivered on the original delivery date of the scheduled project.
Project cost is under the original budget.
Fewer instances of overruns compared with planned allocations for any particular resource (e.g., the plumber doesn’t have to come out twice to do the same thing due to other bottlenecks).
Number of subprojects running simultaneously.

A final benefit of adding structure to the way you manage projects is that it helps your organization develop a formalized and dynamically evolving business process. After developing an initial template, projects get off to a start more quickly, as project-specific obstacles can be anticipated more effectively. Capacities are better understood, helping your company avoid biting off more than it can chew at any particular time. Deliverables become more clearly defined with each iteration of the project plan, which is continuously refined based on each of the organization’s experiences.

Five Must-Have Best Practices

Before beginning a project, engage all the stakeholders necessary to develop and agree upon organizational structure and workflows.
Create a visual map of production processes to increase efficiency and improve strategic decision-making.
Provide clear objectives and an overall benchmark for project success.
Create a single visualization of all project details, tasks and their interdependence that includes a mechanism for tracking status in as close to real-time as possible.
Hold regular, formalized status reviews.

Leveraging Technology

Today, the number-one arrow that an accidental project manager can put in his or her quiver to achieve these best practices is sound technology. Long gone are the days when the only option was pencil and paper, and quickly fading are the days where coordinating dozens of home-brewed spreadsheets are the best option. Project-focused software enables organizations to create and adopt a new process that will increase overall productivity, improve response time when changes are required and provide immediate information on the impact of changes.

Keep in mind it’s not just the tools designed for the folks who launch the space shuttle that can bring this value. Even popular tools such as Microsoft Project are overkill for the average accidental project manager. Instead of trying to train yourself and your entire staff on a complicated software tool with many confusing features your organization is unlikely to use, look for software that cuts to the quick and has a simple, no-nonsense interface. If it’s easy to use, the chance that people working on your projects will adopt it skyrocket, and your projects will reap the benefits.

As well as seeking an easy-to-learn project management solution, choose one that can work well with your existing tools, which may include spreadsheets such as Excel, calendar programs like Outlook or iCal, presentation programs such as PowerPoint and Keynote or accounting packages such as QuickBooks and Microsoft Dynamics. The best project management software can even interact with other applications aimed at the same goals. Choosing a program that can open and modify Microsoft Project files, for example, can go a long way in ensuring that an accidental project manager can work seamlessly with other organizations that use more complex programs to manage projects hour by hour, day by day.

Finally, when possible, seek out software that can work across platforms. For example, often one contractor uses Macs while another uses PCs. A cross-platform software suite can bridge this gap and enable Windows and Mac users to collaborate on projects and seamlessly share vital information.

Although most people don’t realize it, nearly everyone takes on a project management role at some point or another in their daily, professional or even personal lives. Regardless of setting, these accidental project managers deal with the same obstacles – from turf wars to information hoarding to resistance to change. By gleaning best practices from the purposeful project managers – those whose roles focus solely on managing projects, even the occasional project manager can bring new efficiencies to an organization. And that means greater profit. And through methods that promote accountability, thoughtfully planned workflow and collaboration, you can bring order to the chaos of information being thrown your way, reducing your own stress levels and giving you more time for the part of the job you had envisioned when you first entered your field.

Don’t forget to leave your comments below

Dennis Bilowus is President and CEO of AEC Software. He may be reached at [email protected].

[1] http://www.wikipedia.org.