Project Failure Brings Great Lessons

Andrew Makar has an excellent article on Projects@Work outlining key lessons from a prior project failure. I even like his tag line stating that he is "focused on effectively translating project management theory into actual practice." Indeed, that's where the real lessons are to be found.

It looks like it's part of a series---at least a two-parter. This one has lessons about defining clear roles up front, keeping the same project manager throughout the project, maintaining a "living schedule," prioritizing elements in project scope shoulud tradeoffs be needed, and establishing a clear change control process.

I couldn't agree more. Read on...

http://www.projectsatwork.com/content/Articles/235962.cfm

Project Controller: The Project Manager's Best Friend

Halleluyah! Finally, there's an article saying what I've been saying for years. With projects becoming more and more complex, and leadership and stakeholder management requiring more attention than project managers have time for, there's a need for another role to manage the "control" aspects of the project.

This article by Robert Wourms on Projects@Work details how organizations such as State Farm have had success doing just that. Bring on the Project Controller. As a member of the leadership team for PMI's new standards for program management and portfolio management, I witnessed first hand how valuable this role was, as it freed the program manager up to actually lead the program.

The article shows how the project controller's role can include tasks such as:

1) Educating the team on processes
2) Facilitating Planning and Control sessions
3) Developing the project schedule
4) Controlling progress
5) Tracking and analyzing costs
6) Managing Issues, Risks, and Changes
7) Documenting and delivering status information

So what's left for the project manager to do? Plenty. Supporting this, the article offers a valuable table outlining the role of the project manager vs. the program controller. Read on...

http://www.projectsatwork.com/content/Articles/221443.cfm

Executive Support

Continuing the series of posts on Critical Success Factors, we get to Executive Support. This topic is easy to understand. It's also easy for people charged with establishing a PMO to blame lack of executive support for problems they encounter. The fact is that the kind of executive you would want as a sponsor is high enough in the organisation that they will be too busy to give detailed support. So it is essential to have a common description of the relative roles of the change management team and the executive sponsor.

Some commonly quoted expectations for executive support are:
- Visible enthusiasm within the organisation for Project Management philosophy
- Advocacy between organisational groups
- Creation of, or active support for, a vision for the organisation with engrained project management processes
- Removal of barriers to change
- Assurance of funding for the implementation and continued operation of the PMO
- Enthusiasm for the use of project management information and involvement in the processes

It's important that the support should be actionable at a working level. For instance, providing some high level design principles but not insisting on detailed design approval. Or, issuing a public announcement which would then be followed up by detailed posts about specific topics from the team.

This paper describes a sponsor's role in developing project management maturity.
The Executive Sponsor - the Hinge upon which Organisational Project Management Maturity Turns?

Project Team Sizing Heuristics

Nice heuristic --- rule of five for project team sizing. Its good to have a starting framework of roles for projects and modify to the situation. ...

... "When building your next project team think in terms of five and you'll be able to maximize your business and technical capability to deliver a solution on time and on budget. " ...

Via POWERBUILDER DEVELOPER'S JOURNAL: Project Team

Project Management Imperatives: Ten Keys to Success

Someone recently asked me what I felt the critical success factors were for any project (i.e. what were the top "must do's"). Although I can think of many more, here were what I felt were the top ten:

1) Get the roles right. (Insure accountability; use a RACI chart or Responsibility Matrix so roles are clearly defined. Insuring people understand their commitments up front will avoid problems later.)

2) Get the goals right. (Make sure all the key stakeholders agree on the goals. I've seen more projects go wrong for this reason than any other. Time spent here will pay dividends later.)

3) Get the current scope right. (I say "current scope," because change should be expected. Projects by default contain change because they are unique in nature. It's not whether you'll experience change, it's how you analyze the potential impacts and manage the approval of the change that counts. Agreed-upon and approved scope changes are perfectly acceptable, with one caveat: It's often wise to set a limit to the number of times scope can be changed for the current product release, and defer some changes to a subsequent release, else value gets delayed.).

4) Obtain commitment from the business, customers, and other stakeholders as to their part in the success of the project. (Many projects derail because the customer doesn't live up to their side of the bargain, doesn't understand their side of the bargain, or some other necessary constituent isn't cooperating for various reasons. Obtain the right commitment up front, starting with senior management.)

5) Determine the critical success factors and risks. (Critical success factors and risks go hand in hand. Many people ignore this or sweep it under the rug, and accept any related risks as a given. The critical success factors will identify related risks and help set expectations).

6) Set expectations. (This is frequently overlooked and is a key cause of failure. The sponsor, customers, and anyone impacted by the project must be given realistic expectations for what is needed from them, how long the project will take, how much it will cost, what the uncertainty factor is, what the available resources are, and anything else necessary to avoid surprises and/or an under-equipped effort.)

7) Beware of conflicting directives. (I call this the "Robocop Syndrome." In the film, Robocop, the titular robotic policeman goes on full tilt when he encounters directives that conflict with his primary directive. I see this happen often in organizations where a project sponsor demands something that is in conflict with other key stakeholders' wishes and/or top organizational directives. This could be covered under "goals" or "expectations," but it's so important that it warrants its own point. The project manager must head this off at the pass before the project goes down a rat hole it won't recover from.)

8) Plan Collaboratively. (The act of planning is not an isolated exercise. It's a collaborative exercise and should be done with the project core team and subject matter experts via some sort of facilitated brainstorming session---possibly with sticky labels on a wall.)

9) Beware of unilateral and granular "one-size-fits-all" solutions. (This is often ineffective, both as a project management methodology and a process implementation policy. Look at the big picture, and the potential variations. Keeping a framework high-level can allow for greatest flexibility and adaptability. Aim for principles over rules wherever possible. Use rules when safety is involved, regulatory requirements exist, or exact accuracy is needed---per Marcus Buckingham's guidelines from "First Break All the Rules.")

10) Don't let rank set you off course. (Often, a senior manager pulls rank and makes requests that are either detrimental, unwise, or in direct conflict with organizational goals. When this happens, see rules 6 and 7. It is the project manager's responsibility to set the right expectations, warn of potential risks, and head off potential conflicting directives at the pass.)

There it is. My list of "must do's." Project management isn't rocket science. In fact it's not a science at all. It's more of an art. Hopefully, the guidelines above can serve as a useful palette.

IT Governance: Data Security Matters

Take data security seriously and dedicate time in the IT governance agenda for it. Define security policy and create roles / accountability for it through postion of information security officer. ...

... "Formalize an IT governance process with documented policies and controls. Representatives from different departments, including IT, should develop this manual together as a task force led by the ISO. " ...

Via Miami Herald: Link

Soldiers and Heroes: The Right Mix is Key

Derry Simmel, who runs a compelling blog site called About PMOs (and is on the board of PMI's PMO SIG), has an interesting post about heroes and soldiers.

Soldiers, Simmel says, color within the lines and can be expected to be reliable, dedicated, and even anal at times. Heroes break the rules and tend to go their own way---they're about getting it done and getting it done fast. Damn the torpedoes.

But, as Simmell points out, an organization needs both to thrive. True, a team of all heroes can be chaotic, but a team of all soldiers will probably not bring about dramatic change.

It's all about synergy, and putting the right people in the right roles. It's also about the fine balance between exactitude, speed and flexibility (ironically three of Napoleon's six winning principles).

Building a team that capitalizes on the complementary personalities and skills of heroes and soldiers is a good recipe for success.

Here's the blog post...

All about Project Management Offices: Soldiers

Talent and Project Management

I received the latest PM Network magazine from PMI the other day, and several things jumped out at me, especially following my last blog post on the winds of project management changing.

First, Neal Whitten had a great article about how a project analyst (what I've often called a "project control specialist") can be a valuable aid to a project manager by taking on the responsibilities of: project tools management, plan development, sub-plan collection, project support, supporting project tracking meetings, filling in for the project manager at times, and other areas that can free a project manager up to actually lead the project.

It got me thinking about the talents needed for the project manager role, the project analyst/specialist role, and any other roles needed on the project. But more than that, it got me thinking about talent management in general, and what it means to the project management industry.

Just look at these headlines, all from this month's issue:

• Attracting--and Keeping--top talent
• Executive Identity: Project managers should learn to think like executives
• A People Person: Succeeding in project management---and getting what you need from thise around you---requires a well-honed set of people skills
• Virtual Reality: Dispersed project teams are sparking shifts in management and leadership styles

Clearly, the talents needed to manage projects go way beyond schedule, budget, and cost control. Notice I said "talents" as opposed to skills or knowledge. As Marcus Buckingham points out in his excellent book, First Break All the Rules, there is a huge difference between skills, knowledge, and talent. The first two can be taught. The last one--talent--is innate, and cannot be taught.

This becomes clear when you apply Buckingham's definition of talent as "ANY recurring patterns of behavior that can be productively applied." Everyone has talent. It's just a matter of discovering it and matching them to the right role. The key point is that a person's nature cannot change that much, so it's important to select someone with the right talents (i.e. innate traits). Once that's done, you need to set clear expectations, motivate the person (through praise and recognition of their strengths), and ultimately develop the person (building on the strengths that already exist instead of fruitlessly trying to fix weaknesses).

So what does this mean to the project management field? Everything. It means we need to begin thinking about these innate talents when we hire and assign project managers, when we staff the project, and when we consider how to motivate the team. The talents needed for each role will be different. And, based on the nature of the project and the stakeholders involved, the talent required to manage each project may be different. There is no "one size fits all" when it comes to talent selection.

It's not that skills and knowledge aren't important, but these two items without the correct talents will not bring about success.

What I like about Buckingham's book is that it's based on facts---years of research with the Gallup organization. Anyone who selects and manages people should read this book. And when you do, think about the diverse talents needed for each person on your team, and for the project manager role for each individual project.

PMO Process Primer

Last month, I mentioned a four-part series on Projects@Work about establishing PMOs. The first installment was on defining the role of your PMO up front.

Not sure what took so long for the second installment, but it's finally here and worth the wait (maybe it's a monthly series). This installment talks about the types of processes your PMO might undertake, and offers some food for thought with each process area. According to the article, a PMO might consider:

Project Processes (including demand management, approval, portfolio management, project/application lifecycle, and risk mitigation)

Analysis Processes (including business analysis, business case development, and process redesign)

Planning Processes (including planning and tracking, and capital planning and budgeting)

Administration Processes (including methodology management, training, tool development/ownership, and knowledge management)

To date, this series is an excellent primer on PMO startups. It's insightful and obviously written by someone who has had some varied experience in PMO implementation. I'm looking forward to the remaining two parts and will be sure to post the links here.

Kudos to the author, Ted Stephens, an associate principal at Intellilink.

http://www.projectsatwork.com/content/Articles/231627.cfm

The Project Manager and the Business Analyst

There's a superb article on AllPM about the importance of understanding the separate, but related, roles of the project manager and the business analyst.

While it's true that project management has evolved to the point where a project manager must be more like a mini-CEO, with an understanding of marketing, finance, business process, etc. and the ability to speak the language of senior management, we should not confuse that with the need for a separate business analyst that has a deep understanding of the subject matter and requirements.

In my experience, it's foolish and counter-productive to expect the project manager to serve both roles on a large project, even if they are capable.

Here's a link to the article----well worth reading...

Why Does a Project Need a Project Manager and a Business Analyst by Barbara Carkenord :: ALLPM Project Management

The Many Roles of a PMO

There's a great new series in Projects@Work about establishing PMOs. The first installment talks about the importance of defining the role of the PMO right up front.

Here's an excerpt...

"The scope of a PMO's activities can range from a set of limited support roles all the way to decision-making about project priorities, financing, and other governance functions. Defining those roles is the necessary first step in the creation of a PMO that will carry out its mission smoothly and deliver its full value to the business."

It seems so obvious, but many organizations begin implementing a PMO before fully defining, and obtaining organizational buy-in, for the role that the PMO will serve. I'd also add that many organizations begin with too broad a scope and in doing so, form a wall between the PMO and the est of the organization. It's OK to have a multi-tiered vision, with an initial state for the PMO and a longer-term, broader vision.

Here's the full article (the next installment is on PMO processes)...

http://www.projectsatwork.com/content/Articles/231325.cfm:

Join the Project Management Revolution; The SOPM Model Takes Shape

OK, I've been fleshing out the Service-Oriented Project Management (SOPM)™ model, and have come up with a more memorable and catchy representation of the four steps, although the actual content is pretty much the same.

The acronym for the four phases is UP-IT (which can symbolize "upping" the level of customer service, saying "up yours" to old ways of doing things, or "upping" the success rates of IT projects---in which case the "it" stands for "IT").

Ready??? Drum roll please......

The four phases are:

• Understand
• Prepare
• Iterate
• Transform

Here's a revision of my previous post on the topic...

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer and what they need to be successful.

2) PREPARE ... After helping the customer obtain approvals if needed, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Using the axiom, "Think bold, implement safely," plan, design, build, test and pilot the solution before attempting a full scale implementation. Encourage innovation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) TRANSFORM... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected) for the purpose of transforming yourself and the customer for the better. This includes guiding the customer to help them achieve maximum results with the product or service delivered, and laying the groundwork for their continued success.

Now that I have the framework locked in, I'll complete the model around these four phases. I am absolutely convinced that this model can help increase customer satisfaction and the general success rates of projects.

SOPM; A New Project Management Methodology

Service Oriented Project Management (SOPM) is taking shape as a methodology that fills the gaps in traditional project management, namely a RELENTLESS customer focus and the all-important analysis and benefits evaluation after the project has "completed."

As I fine tune the model, I'll post the iterations here, as a methodology in progress.

The four high-level steps in SOPM are as follows:

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer.

2) ENABLE ... After helping the customer obtain approvals, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Plan, design, build, test and pilot the solution before attempting a full scale implementation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) EVALUATE... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected). This includes evaluating how the customer can achieve maximum results with the product of the project, and laying the groundwork for their continued success.

By using an UNDERSTAND, ENABLE, ITERATE, and EVALUATE process, with COMMUNICATE as an overarching activity that extends across all four steps, we adopt a much more holistic and customer-centered approach to project management.

A few key points... Customer satisfaction should be measured at milestones throughout the project, not just at the end. It's as important as monitoring cost and schedule (i.e. Earned Value performance).

Imagine seeing an S-Curve showing Planned Value, Earned Value, Actual Cost, and Customer Satisfaction. Maybe your project is on schedule and on budget, but the customer isn't satisfied with the results (or with the project communication, or a whole host of other issues).

A narrow focus on cost and schedule takes too much of an inward view. Besides, measuring customer satisfaction throughout a project allows for corrective action instead of managing in the rear view mirror.

More to come.

NOTE: I have since revised this model. See my updated entry.

Succeeding with Multi-Cultural Projects; Personal Touch is Key

There's a good article in Computerworld about how to succeed when managing multi-cultural and virtual projects. No surprise, many of these projects are doomed before they get past the requirements phase.

Key points mentioned include the importance of one-on-one communication (as opposed to surveys, etc.), establishing a RACI chart for roles and responsibilities, and modeling the requirements via prototypes and process models, etc.

Here's the full article...

Projects Without Borders: Gathering Requirements on a Multicultural Project - Computerworld

Innovation and Project Management - Part 1 of 3

As I had mentioned previously, The Ten Faces of Innovation, by Tom Kelly of IDEO, with Jonathan Littman, is an excellent book on how to create a truly innovative environment (as opposed to just saying "from now on, we're going to be innovative").

Some think that innovation has nothing to do with project management---that innovation is about generating ideas, and project management is merely about executing them. In my view, this is absolutely wrong, as you will hopefully see as I share a summary of Tom Kelley's "Ten Faces of Innovation."

Even as a summary, there's a lot to share, so I'm breaking this into three parts. Each part will share one of the three groups of "personas" Kelley covers in the book; The Learning Personas, The Organizing Personas, and the Building Personas. In this post, I'll summarize The Learning Personas.

As noted in the book, it's important to note that each persona is just that, and not a "position". Some people can have multiple roles, and not all roles are needed on every project. But in general, the more roles that are covered, the more successful your venture will be.

Meanwhile, here are the first three personas, adapted from the book, with my own comments added (keep in mind that the book offers a heap of antectodal information that supports these personas---real stories from real companies).

The Learning Personas

1) The Anthropologist – Observes human behavior and empathizes in order to determine what’s really needed. Fanatically keeps lists of issues and ideas. [As Toyota's slogan goes, “Go and see for yourself.” Don’t judge by a needs survey alone.] Henry Ford said, “If I had asked my customers what they wanted, they’d have said a faster horse.”

2) The Experimenter – Likes to try new avenues, using fast, inexpensive prototypes. Not afraid to think out of the box and “fail often to succeed sooner.” Uses enlightened trial and error. Can also do "implementation by experimentation" for multi-locations by engaging remote sites in prototyping, and letting them adapt to their site as needed (as opposed to a rigid “rollout”).

3) The Cross Pollinator – Examines other industries, genres, and cultures, to mine for ideas and look for analogies. These are typically “T-shaped” people, with a deep understanding of at least one core area and a broad interest in many other topics. Well-rounded, and with many interests, these people are a core source of ideas.

As you can hopefully, see, these learning personas are quite applicable to project management and cannot be divorced from the process of taking an idea and turning it into reality---and isn't that what project management is all about?

Up next in part 2, The Organizing Personas...

ITIL Implementation Webcast Advice ...

Recent webcast by Managed Objects validates the hype associated with ITIL implementation. Some good advice was shared: Adopt ITIL in small pieces with a focus on top business services and their key performance indicators. Avoid the proliferation of tools to support ITIL adoption. Some not-so-good advice was evident: Select tools first and then automate processes.

I would recommend focusing on the process first, redesign as necessary, train and support people in their roles, and then implement tools in stages consistent with your desired change in process maturity. ...

... "Over 500 registrants for the webcast validated that the ITIL adoption topic is top-of-mind for many enterprises today. In fact, according to Forrester Research, with in the past year ITIL adoption of $1B+ revenue companies has increased from 13% to 20% , with that number projected to grow to 60-70% by 2008. " ...

ITIL Implementation Webcast Advice: Via Managed Objects: Business Service Management Required for Successful ITIL Adoption: Independent Research Firm tightly links BSM and ITIL Best Practices during recent Webcast ...

IT SOA Strategy: Form Architecture Group ...

What is the role of an IT architecture group with regards to SOA? Ajit Sagar shares his experiences with developing the architecture organization. He recommends a more formalized architecture function to support SOA standards and performance agreements. I like his ideas regarding a more active and involved architecture team that interacts regularly in projects, in addition to traditional roles, such as publishing reference architecture documents. Good advice ....

... "One of the main responsibilities is also to align with the business to define the IT strategy for SOA and to provide an implementation roadmap, including the migration of existing applications towards a service-oriented paradigm. " ...

IT SOA Strategy: Form Architecture Group: Via Sys-Con Italia: Architecting for SOA ...

Project Management: Virtual Decision Making

Struggling with enabling and sustaining project decisions? Bill Thomas promotes effective decision-making through a process that considers the level of decision-making participation and measures performance. The decision roles of participants should be understood, documented, and monitored (helpful with compliance, such as SOX). Graphical visualization of key measures is recommended, in combination with the appropriate commentary to provide the color and texture of the business context. ...

... "Effective group decision making within performance management has always been a challenge, but traditional decision-making approaches do not consider the speed and complexity of dynamic virtual work teams regularly employed at this time. They also neglect recent compliance regulations that have a direct impact on defining current business processes. Ten years ago, an organization could employ loose guidelines and/or project management techniques because group decision making was less complicated. " ...

Via Business Intelligence Network: Decision Making and Risk within the Performance Management Process ...

Mining for Talent; Fielding a Good Project Team

Tom Peters has been blogging about a book by Dennis Littky called The Big Picture: Education is Everyone's Business. Now I can see why. I purchased the book and it's revolutionary. Littky is a pioneer in the education industry and has achieved startling results with his focus on students as individuals. But the book isn't just for those in education, it's for anyone in a leadership role.

Much like the theme of How Full is Your Bucket, the subject of my previous post, it focuses on finding the hidden talents in the individual, and not just basing decisions on grades, scores, or averages. I'm still reading it, so I'm sure I'll be posting more on it in the near future, but so far it's a very enlightening book, and makes so much sense it's scary.

I've always subscribed to this philosophy, as I feel that fielding a good team in business is no different than fielding a good team in sports. You need to find people's desires and areas of talent (nearly everyone has some), encourage them to build on that talent, and put them in the right positions to exercise that talent. Combined with positive reinforcement (which elevates their self-confidence), they will shine as individuals, and if well-matched with others (team dynamics), the team will shine as well.

I recently saw yet another source that supports this theme of "mining for talents." I just subscribed to Leadership Excellence magazine (and in fact have been asked to submit an article to them, which will most likely appear in their April issue). On their website, I saw this quote from leadership guru Warren Bennis...

“It became clear to me that to understand Drucker’s philosophy of management, you need to know his philosophy of education. In fact, they are one and the same: Honor individual differences. Take people as they are. Don’t attempt to change or manipulate them to be like or to become somebody else. There is no one right way. Organizations are as much learning environments as they are socially useful institutions established to produce goods. At their best, they make available sufficient roles where individual strengths can contribute to productivity and where individual weaknesses are irrelevant. There is virtually no such thing as an ineffective worker, only a worker whose areas of competence are inappropriate for a particular role.”

—Warren Bennis, consultant,
Leadership Excellence, January 2006

Very inspiring words.

PMO Project Office: Whirlpool Maytag Integration ...

Whirlpool makes leadership moves to support the integration of the planned Maytag acquisition in a controlled and disciplined manner through a project management office, or PMO. Appointed execs bring strong credentials to their new leadership roles. ...

... "Whirlpool Corporation announced the appointment of Ted Dosch, currently corporate vice president and controller, to corporate vice president, finance, Project Management Office, which manages the planning and integration of the anticipated Maytag acquisition. Larry Venturelli, currently vice president, Investor Relations, will succeed Dosch as vice president and controller. These moves are effective immediately. ... In his new role, Dosch will lead the planning and integration of all financial processes and internal controls associated with the anticipated Maytag acquisition. Venturelli will assume the controller responsibilities and continue to provide leadership to the Investor Relations activities on an interim basis. A successor to Venturelli will be named at a later date. Both Dosch and Venturelli will continue reporting to Templin. " ...

PMO Project Office: Whirlpool Maytag Integration: Via Whirlpool: Whirlpool Names Dosch and Venturelli to New Leadership Roles ...



Whirlpool Corporation is a global manufacturer and marketer of major home appliances, with annual sales of more than $13 billion, 68,000 employees, and nearly 50 manufacturing and technology research centers around the globe. The company markets Whirlpool, KitchenAid, Brastemp, Bauknecht, Consul and other major brand names to consumers in more than 170 countries.

IT Governance Excellence: Conference Workshop ...

Intellilink offers services in IT governance excellence. At recent project management conference, Intellilink leaders present workshop on solutions for accelerating the implementation of IT governance. ...

IT Governance Excellence: Conference Workshop: Via Intellilink Solutions: Intellilink Solutions Hosts IT Governance Workshop at ProjectWorld USA 2005: Company executives share their expertise to resolve the most critical issues encountered when implementing IT governance ...

... "The Intellilink workshop, Solving People and Process Issues When Implementing IT Governance, was run jointly by Intellilink's CEO, Patrick Boylan, and Managing Director, Fumiko Kondo, who are both leading experts in deploying solutions for IT governance for clients across a range of industries. In addition to offering real-world solutions to common IT governance issues, the interactive event outlined typical IT governance business models and detailed common roles, responsibilities and business processes. " ...

People-Focused Project Management; Parkinson's Law Repackaged

Maybe you've heard of Parkinson's Law; "Work expands to fill the time alotted." In other words, if you give someone 10 days to complete a task, they'll take the full 10 days, either by adding unnecessary features during the leftover time, or by waiting until the last minute to complete the work (also called "Student Syndrome").

Well, the same thing applies to the roles we brand people with. We can repackage Parkinson's Law as; "Performance Expands to Fill the Role Alotted." If we give people stretch goals, and brand them with a role or image that is slightly ahead of where they are, they'll stretch to live up to that role. Unfortunately, the reverse is also true.

If we pidgeonhole someone into the role they've always filled (or worse, a less important role), they'll usually limit their performance accordingly.

It's important for morale, employee retention, and the good of the project, to give people goals that will stretch them a little. But this doesn't mean to throw them at the wolves and see if they emerge with their limbs intact. It mean we need to offer the guidance, coaching, and tools for them to be successful.

I've seen too many organizations focus on tools and processes, and only give lip service to their people. They either brand people with an image based on some preconceived idea of their ability, or they give people stretch goals without any guidance or coaching whatsoever. I'd be hard pressed to say which is worse, but neither are good.

Let's remember that it's people that can make or break an organization, even with the best tools and processes. Let's give them the attention and support they deserve.

Increase IT Career Opportunities with Certifications & Education

This July 2005 article titled, "IT Certification: Increasing Women’s Career Opportunities" really could apply to anyone who may feel they aren't being taken as seriously as they should be. Some key points:

• For whatever reasons, there are STILL few women in senior IT and business roles
• Respected and relevant certifications/education can help to establish credibility and increase leadership opportunities (the key words are respected and relevant - if your company doesn't respect a Master's in Liberal Arts from City College, it probably isn't going to get you the corner office at THAT firm, but it may help you find your next job at a firm that values education in general; perhaps a Master's in Comp Sci or a certificate in Project Management from PMI (yes I am biased) would be more respected by your firm and relevant to your job, for example, and hey, it doesn't take as much time to achieve either)
• Most respected certification programs demand continual education and training for retaining the designation (PMI's Project Management Professional (PMP) is no exception)
• IT security and governance programs are reaching the top levels of organizations today - who are they going to choose to lead these important efforts? Someone with a string of respected and relevant certifications or not?

The answer is clear. Eat your alphabet soup - but pick out only the respected and relevant letters.

CertMag.com IT Certification: Increasing Women�s Career Opportunities

Project Portfolio Management: Organizational Change Perspective PPM

Jeff Monteforte, from Exential, explores best practices in driving adoption of information technology (IT) project portfolio management (PPM) by enabling organization change. He emphasizes a holistic view of the portfolio, new PPM roles and responsibilities, sound financials, and effective governance bodies. ...

Project Portfolio Management: Organizational Change Perspective PPM: Via CIO Update: The Six Sins of PPM

... " ... you must realize that managing the organizational change is more important and more difficult than building the process; and, second, the PPM process is not an IT process, but a corporate process that has provides huge benefits for the IT department. ... " ...

Managing Business Intelligence (BI) Projects; A Primer

From Addison-Wesley comes a great article outlining a roadmap for managing BI projects. As the article points out, BI projects are not for the faint of heart.

It lays out preparation activities, key roles, and other tips and techniques. But even if you're not managing a BI project, there's great advice here for anyone managing a large scale technical project. Check it out...

A Business Intelligence Roadmap: Project Planning

Are Your Project Managers Slowed Down by Bureaucracy? Consider Adding a Project Administrator

So many project managers get bogged down in administrative details that it dilutes their efforts on focusing on their three most important roles--communicator, planner, and leader.

Some organizations "get it" and assign a Project Administrator to address procurement management, financial management, project setup, timesheet processing, travel arrangements, and other administrative functions that will slow down the project manager.

As I mentioned in a previous post, some organizations even appoint an additional person as Project Control Specialist, to maintain the project schedule, risk list, issues list, etc.

I've seen both of these roles used with great success, and it showed in the project manager's ability to focus on the key issues facing the project. Unfortunately, these important roles are often overlooked, and the project manager attempts to do it all to the detriment of the project.

I'd be curious to see how many others use a Project Administrator and/or Project Control Specialist, and the impact it's had on your project (or how these roles might help your projects).

Hurricane Katrina and Project Management Discussion ...

More Hurricane Katrina and Project Management - Via Project Perfect - Project Management

What can we learn from and improve upon in the Hurrican Katrina experience ...

... "Another interesting aspect of the hurricane from a project management perspective was the issue of defining roles and responsibilities." ...