Yet another top 10 PM trends list for 2009

Well it is 2009 and a lot has changed since last year, especially in the economic climate that we now occupy, and for those in the profession of project management it is inevitable that you will be effected by it as well as try and prognosticate on the future trends you may encounter. And sure enough, ESI International which is a consultancy and training company for all things project management related, published it's Top 10 Project Management Trends for 2009 which are outlined below:

1. The Sandwich Generation: Middle Managers’ Emerging Role in Change

Seventy-five percent of all change management programs fail because of a lack of employee support. Today’s economy will force organizations to confront the important roles middle managers play in the success of change efforts. Middle managers’ roles will shift from simple messenger of directives ‘from above’ to creating a positive environment to enable change, accountability and ownership of change initiatives, achieving the full benefits of change and ensuring return on investment.

2. Navigating Virtual Teams through Change

As budgets tighten, the role of virtual teams will grow along with the demand for the skill sets to manage them, especially through change. Powerful communication, key management strategies and new rules of engagement will be required to manage virtual teams as organizations seek to effectively shift with the turbulent global economy.

3. Sharper Distinctions Between Project and Program Management

Many global organizations have managed programs with the same methods used to manage projects, with predictably disappointing results. Programs are not merely “bigger” projects, and program managers aren’t simply professionals who are one step up on the organizational ladder. This year will see an increase in the understanding of the cardinal differences between projects and programs and the utilization of strategies to boost program managers’ effectiveness and increase program success.

4. Leveraging Communities of Practice To Hone Skills

The number and importance of project management communities of practice will increase significantly in 2009. These informal communities will be highly prized for the lack of bureaucracy that increase the sharing and use of best practices, enabling increased dialogue to overcome challenges and growing future leaders.

5. Strategic Selling of the Project Management Office

Although the project management office has gained wide acceptance, it still needs buy-in at the senior executive level. 2009 will see an increase in the importance of quantifying the PMO’s value and how to present that data to the CFO to ensure funding in what promises to be highly competitive arena for organizational resources.

6. Back to Basics for Successful Project Portfolio Management

More than any year in recent history, 2009 will be a critical year for ensuring project success. Project managers will increase their emphasis on the basics, taking a first-things-first approach and address fundamentals such as gaining and sustaining executive commitment, addressing gaps in the alignment of organizational strategy and projects, project selection, and efficient measurement process while leveraging existing resources to increase project success.

7. Right-sizing Staff with Demand Driven Resource Management

The adoption of Demand Driven Resource Management will increase significantly in 2009. Its ability to right-size internal staff and draw on outside contractors when demand requires will be viewed as an essential cost containment approach leading to greater organizational performance and efficiency.

8. Improved Requirements Metrics

The economic need to accurately assess and evaluate the organizational and cost impact of project requirements will bring a greater role for requirements management and development. Also known as business analysis, RMD’s ability to provide quality metrics that project and portfolio managers can use to assess the economic, performance and feasibility value of each project component will become essential to organizations successfully maximizing the ROI of their projects.

9. People Will Come Before Technology

Organizations will increase their demands for smart third-party guidance that ensures technology investments deliver enhanced performance. This will result in greater recognition of the critical role people play, leading to increased recognition that employees need the right skills and knowledge before applying processes for consistency and adding technology to deliver increased efficiencies.

10. Risk Management for Governance

In 2009, many organizations will say goodbye to the ‘one number’ method for project outcomes and embrace a quantifiable range of potential results on which to base decisions. Recognizing that best governance hinges on the availability of quality information at the project level, education and leadership in risk management and best practices permeate organizations wanting to optimize project forecasting to deliver more effective governance.

I can't help but to feel that you could look at a similar list 5 or even 10 years ago and see the same projected trends. Though I don't have evidence for it, my assumption is that there is more recognition throughout companies of the importance of these 10 initiatives if you had measured and collected the information and compared it with the past. Sadly, I would think that the progress of these 10 trends would not be as progressive.

Of particular interest to me is change and demand resource management, as well as risk management and governance. Many companies just don't get these right.

Top 15 highest paying IT certifications

I got directed to this link from Erika Flora's blog, which is based on a ZDNET Tech Republic survey which outlines the top 15 IT certifications you can get right now:

1. PMP (approx. $101k)
2. CAPM
3. ITIL Foundation
4. CISSP
5. CCIE
6. CCVP
7. ITIL Master
8. MSCD
9. CCNP
10. Red Hat Certified Engineer
11. MCITP (Enterprise)
12. CCSP
13. MCAD
14. MCITP (Database)
15. MCDBA (approx. $76K)

One major issue I have with these results is that it lists the CAPM as #2, and from what I understand it has had very little traction and seems unlikely that it would supercede the other certifications. Another minor issue is that the PMP certification is not a IT specific one, as project management can be and is utitilized accross industies and company departments. Otherwise, I would not be surprised to know that PMPs involved in IT get the best pay, since most who get the certification are experienced project managers.

Managing projects in the "Cloud"

The current issue of the Economist has a special report on Corporate IT and the central theme of the articles is the recent rise of cloud computing and its effects on the governance and management of IT initiatives in the corporate world:

Computing is taking on yet another new shape. It is becoming more centralised again as some of the activity moves into data centres. But more importantly, it is turning into what has come to be called a “cloud”, or collections of clouds. Computing power will become more and more disembodied and will be consumed where and when it is needed.

The rise of the cloud is more than just another platform shift that gets geeks excited. It will undoubtedly transform the information technology (IT) industry, but it will also profoundly change the way people work and companies operate. It will allow digital technology to penetrate every nook and cranny of the economy and of society, creating some tricky political problems along the way.

Because of the dot com bubble of the late 90s, I'm very skeptical to even cynical of such hyperbolie, but in this case I think a majority of the hype is justifed. The key term from the quote above is "disembodied", which is a pretty good way of describing the cloud. Terms such as decentralized, fragmented, and dispirate was and is still used to describe the networks which comprise the internet, but a more stronger term such as disembodied would need to be used to describe clould computing as it allows you to grab a software service from a totally abstracted layer that conceals a very complex infrastructure of data centers and virtualized storage technologies.

The image below from Wikipedia provides a pretty simplified pictorial of this architecture:


In addition, it list the key charactersitics of the Cloud:

• Capital expenditure minimized and thus low barrier to entry as infrastructure is owned by the provider and does not need to be purchased for one-time or infrequent intensive computing tasks. Services are typically being available to or specifically targeting retail consumers and small businesses.
• Device and location independence^[25] which enables users to access systems regardless of location or what device they are using (eg PC, mobile).
• Multitenancy enabling sharing of resources (and costs) among a large pool of users, allowing for:
  • Centralization of infrastructure in areas with lower costs (eg real estate, electricity)
  • Peak-load capacity increases (users need not engineer for highest possible load levels)
  • Utilization and efficiency improvements for systems that are often only 10-20% utilized.^[21]
• Performance is monitored and consistent but can be affected by insufficient bandwidth or high network load.
• Reliability by way of multiple redundant sites, which makes it suitable for business continuity and disaster recovery,^[26] however IT and business managers are able to do little when an outage hits them.^[27] Historical data on cloud outages is tracked in the Cloud Computing Incidents Database.^[28]
• Scalability which meets changing user demands (e.g. Flash Crowds) quickly, without having to engineer for peak loads. Massive scalability and large user bases are common but not an absolute requirement.
• Security which typically improves due to centralization of data, increased security-focused resources, etc. but which raises concerns about loss of control over certain sensitive data. Accesses are typically logged but accessing the audit logs themselves can be difficult or impossible.
• Sustainability through improved resource utilisation, more efficient systems and carbon neutrality.^[29]

So from a business point of view, you can view cloud computing as a broad array of web-based services aimed at allowing users to obtain a wide range of functional capabilities on a 'pay-as-you-go' basis that previously required tremendous hardware/software investments and professional skills to acquire. Cloud computing is the realization of the earlier ideals of utility computing without the technical complexities or complicated deployment worries. Therefore, in a nutshell, cloud computing seems to promise limitless computing power and storage space via the internet.

I have no doubt that some day this type of ubiquitous computing availability and services will come about. A tremendous amount has changed since that decade or so when the internet became a truly viable commercial technology. It has no doubt experienced bumps along the way, but there are utility services we enjoy today such as electricity, water and gas that we can acquire without having to think much about it and the downtimes are nearly non-existent, but I'm sure at the beginning had reliability and quality issues.

The Economist articles points out the potential problems to watch for such as reliability, security and ownership of data and information. These are very valid and obvious concerns to me, but one that concerns me the most as person who manages multiple projects that almost always have a IT component to them, is that before cloud computing resolves the common issues of reliability, security, etc. and becomes as ubiquitous and easy to use as utility services, there will be that ramp up curve wherein companies that adopt the cloud and tires to resolve all these issues makes a person like me who has to manage these projects get gravely effected by it.

Furthermore, even without cloud computing, there was a problem of too much software being built and/or purchased by companies looking to automate every process for cost savings or competitive advantage. This came at a very big cost in terms of infrastructure and application investments and caused huge project overruns that delivered applications that brought very little or no value to business. Cloud computing will help with the cost for infrastructure and application implementation, but in many ways the ease with which companies would be able to pick, purchase and use software services will cause more delays and little value, and though cost may be saved in the short run, time will be lost and in business, time is money.

Project managers will have no choice but to adopt a more agile approach, but for many companies such as the one I work for, there is still a need to comply with regulatory agencies such as HIPAA and SOX, which require a process and audit trail to be followed. Its hard enough now to balance these competing needs, I see the adoption of cloud computing with the potential to exacerbate this problem even further.

So while cloud computing promises much, there needs to be a healthy skepticism in one's evaluation of it's benefits.

Oracle acquires Primavera

Ran into this press release from Oracle announcing the acquisition of Primavera, one of the major players in the enterprise PPM solution space:

On October 8, 2008, Oracle announced it has entered into an agreement to acquire Primavera Software, Inc., a leading provider of Project Portfolio Management (PPM) solutions for project-intensive industries. The transaction is subject to customary closing conditions and is expected to close in the second half of 2008. Until the deal closes, each company will continue to operate independently.

Primavera offers best-in-class solutions focused on the mission critical PPM requirements of key vertical industries including engineering and construction, public sector, aerospace and defense, utilities, oil and gas, manufacturing and high tech, and IT and services. Primavera helps more than 5,000 global customers and over 2.5 million users propose, prioritize, select, plan, manage, and control complex projects.

Primavera's PPM products, together with Oracle's project financials, human resources, supply chain management, product lifecycle management, business intelligence, and infrastructure software are expected to provide the first, comprehensive Enterprise Project Portfolio Management solution. This solution is expected to help companies optimize resources and the supply chain, reduce costs, manage changes, meet delivery dates, and ultimately make better decisions, all by using real-time data.

This is interesting news to me since I manage a similar PPM product for my company, and it indicates the growth of this enterprise software space and the starting of its consolidation.

Niku was acquired by CA and reanamed CA Clarity, Primavera by Oracle, so the next logical aquisition might be Planview by SAP?

Can IT be run like a business?

With the economy in a downturn, the continual decreasing costs of technology and the hype around internet technology and the exuberant spending of the late 90s now a distant memory, there has been a push to treat the IT department like a business. In some cases, the idea of treating IT as a business unit in and of itself, to treating IT as a portfolio of investments much like stock and mutual fund portfolios, has been thrown around.

In my opinion, these viewpoints came about due to several factors, such as the fear of outsourcing, diminishing returns and competitive advantage, and the fact that IT has not always (and some could argue for the most part) created real business value from an organizational as well as end user perspective. I think it is this last case that really justifies the notion of running IT like a business or at the very least with the business value as it's main driver. But while a great idea (and yet to be implemented in many companies), I think some careful thought has to be done before deciding to turn IT department as another arm of the finance department. I think first of all, you would have to evaluate your company's core competencies and decide if the model of running the IT department as a generator of investments and revenue that will need to keep an eye on things like cash flow and earnings would truly benefit the company. As this CIO article points out:

However, alongside the benefits of running the IT department like a business, there are also risks and pitfalls. The most damaging to the CIO's longer-term strategy is any attempt to run the department as a separate business rather than just running it in a more businesslike way.

There's a world of difference between running the IT department "like" a business, and trying to run it "as" one. It's amazing how one word can fundamentally alter strategy. Running IT like a business means adopting a businesslike mindset, processes and financial disciplines. Running it as a business means competing for revenue and investment in an open market, and going bankrupt if you run out of cash to cover your liabilities.

What happens if a CIO attempts to run her department as a business? Colleagues in other departments will perceive that the IT department wants to be treated like a supplier. If the CIO's chosen business is primarily to be a provider of operational IT services, then that what is her "customers" expect her to concentrate on. In that case, contributing to corporate and business strategies will be a heroic, uphill battle rather than the IT department's core contribution to the enterprise. The prevalence of heroic how-we-in-IT-contributed-to-strategy stories in the media offers us insight into how much IT's strategic contribution is currently considered exceptional, rather than its stock-in-trade.

The IT department might find another pitfall if it tries too hard to run itself as a business. The company's business units will be reluctant to fund any material investment by IT in anything that looks like branding, marketing, selling or upgrading the management systems that support the IT department's own productivity. Why should they? One of the primary cost advantages of an internal department is that it doesn't require all the capabilities a real supplier needs to compete in the open market. So the CIO is caught. She has placed herself in competition with bona fide external suppliers but without access to the investment that they have in order to compete as an equal.

In the long term, the IT department will find itself in a corner from which escape becomes ever more difficult. It lacks the means to compete with real IT suppliers and has separated itself from the business that it is meant to be part of. It wants to be taken seriously in the world of strategy, yet its primary business is operational. This is when taking "IT department as a business" too far seriously undermines the next generation strategy for IT.

In my opinion, the majority of IT departments do not build technology and services to end user customers, but is really just another component of the organization needed to keep the operations running day to day. If this is the operating model and core competency of the IT organization, then it must fulfill its obligation to upgrade, maintain and support IT services and have the cost of these services measured against the benefits derived from them. Any department within a company must fulfill this obligation otherwise the will find themselves downsized or reorganized. It probably stems from the love/hate relationship most non-IT departments have with IT that IT is always being asked to justify its existence to business, and is always the first department to experience cuts, downsizing and outsourcing.

On the other hand, if a company's core competency and operating model require a close alignment with IT and strategic initiatives, then adopting a PPM methodology with respect to the selection and prioritization of IT initiatives and projects becomes critical. You would then need to measure these initiatives and projects against the avaialbility of financial, human and technical capacity and allocate them appropriately. In a sense, you are managing IT like a stock portfolio:

The concept of portfolio management comes from the financial investment world. The idea is to manage corporate IT projects like financial portfolios, balancing riskier projects with safer "blue chip" technology investments, then constantly monitor the whole shebang to make sure that the risk/reward ratio never gets out of whack.

Portfolio management not only saves money, but it can help CIOs truly integrate business goals into the IT project planning process.

But probably the more important consideration would be the leadership within IT and their ability to accurately align the core competency, organizational culture, and management agenda with IT investments in a strategic manner:

Unless the company is already an expert customer of IT, its people will need strategic leadership from trusted colleagues who do not have a vested interest in supplying technology services. If the IT department is behaving as a business supplying operational IT services, then who can everyone trust to provide the strategic leadership that the next generation of IT strategy demands?

A CIO who is trying to run the IT department as if it were a separate business will need to rethink her operating model. What have others done in such circumstances? They have divided their department's activities into two groups: core capabilities and services. Core capabilities are those IT-related activities that the company must have in-house and that make the company an expert customer of technology. Services are the activities that the company can choose to either keep in-house or outsource. Naturally, the CIO's own activities should be included under core capabilities rather than services.

Having divided her IT department's activities into these two categories, the CIO can benchmark her company's core IT-related capabilities against the models that other innovative companies are using. In particular, the company should excel at true enterprise architecture (not just its technology components) and investing in business change. Together, these are the engine of strategic investment and value creation, both for IT and everything else. And they should be supported by robust sourcing to spend that investment wisely.

Of course it always boils down to something as fundamental as having good leadership, but given the widely held perception of IT as just another cost center, the short tenure of CIOs, and the inability of most corporations to properly execute project and portfolio management, that it will be some time and take a great leader to break this cycle.

Government waste in IT

In my current profession of managing projects, cost overruns and delays are notoriously common so it should be no surprise that I run into this article about the billions that are wasted in IT projects for the government. It was based on a study released by the GAO which I actually downloaded and read and found what was revealed to be quite interesting. It states right off the bat that:

OMB and federal agencies have identified approximately 413 IT projects—totaling at least $25.2 billion in expenditures for fiscal year 2008—as being poorly planned, poorly performing, or both. Specifically, through the Management Watch List process, OMB determined that 352 projects (totaling about $23.4 billion) are poorly planned. In addition, agencies reported that 87 of their high-risk projects (totaling about $4.8 billion) were poorly performing. Twenty-six projects (totaling about $3 billion) are considered both poorly planned and poorly performing...

In our rebaselining review, we project that 48 percent of the federal government’s major IT projects have been rebaselined for several reasons, including changes in project goals and changes in funding. Of those rebaselined projects, 51 percent were rebaselined at least twice, and about 11 percent were rebaselined 4 times or more. In addition, while the major agencies had all established rebaselining policies, these policies were not comprehensive. Specifically, none of the policies were fully consistent with best practices, including describing a process for developing a new baseline and requiring the validation of the new baseline.

The study outlines the cause of these problems relating to such things as being unable to properly prioritize projects and portfolios, not getting executive sponsorship and not having the proper project management processes in place. Hmm, I don't see how this is really different from what I see in the private sector so it should be no surprise to see these problems so prevalent in the gigantic and bureaucratic government sector.

I found some of the comments on the article not only illuminating, but quite entertaining:

"Why Do Government IT Projects Fail"

By: Tom Ryan
at: 08-04-08 @ 11:32 am EST

Why Do Government IT Projects Fail? I have been involved with a few Local and Federal projects from both the agency side and the contractor side.

Failure for many of the agencies begin even before the RFP is sent out for bidding. The lack of documentation, skilled professionals, and understanding of the the total impact of a project plays a huge hindrance on the scoping and bidding process. Once the process has begun and a vendor is chosen is when all havoc breaks loose.

First and foremost, when working with the government, be prepared to go over budget just from meeting. They have meetings than meeting about the previous meeting. Than 8 hours of your day is in meetings, leaving you only 4 to 6 hours to work afterwards. Once everything is laid out on paper, and the project is about to begin, than the scope creep begins. Because of the scope creep, then legal has to approve the new changes (Lawyers work at a slow pace when reviewing contract changes). While thoose changes are going on, you have 50 consultants sitting around doing nothing. (50 times 2000 dollars a day adds up rapidly).

Now from the contracted company side. No one has 50 people sitting on the sidelines waiting for work. So their is a huge head hunter search for people to work on the project. Sometimes people are imported in on Visas depending on the classification of the work they are doing.

The next issue is the different skillsets you may encounter and the different mindsets. Some work harder and faster than others. Some complain too much. Personalities clash.

Then you have the project managers that lack the experience and promise to over deliver. This causes the top professionals to overwork themselves and get burned out to try and appease what the Project Manager promised to deliver.

Then comes the other scenario. Some projects are just TOO BIG. A company is never going to say NO to a project that is too big and far out of their capabilities. I have seen a few cases where a project is so big, all the network hardware and software was deprecated twice before the project was completed. Big projects will always fail because technologies change too rapidly.

"Licensure, anyone?"

By: John Dyer
at: 08-04-08 @ 1:00 pm EST

I own an IT consultancy that has served more than 100 clients since 1986. Most of our clients have been companies with revenue exceeding $100 Million. I regret to say that the incompetence I have witnessed over the years makes me wonder how our country will maintain its position as a world economic power.

I believe that a core issue affecting performance in IT is the lack of a credible credentialing authority, lack of uniform standards for IT curricula, lack of licensing for IT professionals and finally, lack of adjudication and peer review processes.

As it stands today, anyone can hang out a shingle declaring themselves to be an IT professional. The customer has no way of telling the difference: Anyone who knows 50 things more about computers than themselves looks like a genius.

What else could we expect to come from this setting? The industry is plagued by an army of pretenders and consequently IT runs on square wheels.

That said, not everyone can be a cabinet maker: Were it not for carpenters of average ability, we'd all be living outside. In the construction business, however, only licensed engineers get to work on critical load calculations. In IT, anybody can do it. Shame on us!

The Business of Constraints

Found a very interesting YouTube video that does a good job of outlining the Critical Chain theory:





I mostly know Critical Chain from the perspective of Critical Chain Project Management (CCPM) or Critical Chain Method (CCM) which is typically considered the Betamax of traditional Critical Path Method (CPM) that is used as a project management methodology to build a schedule. CPM is a feature which allows a project manager to create predecessor and successor tasks to determine the longest path of his/her schedule, thus making it a "critical" path. Pretty much all the project scheduling software out there has this feature.

One of the big flaws of this approach is that it assumes you are able to apply as many resources to the path to keep your project on time, when in reality nearly all project managers work in a resource constrained environment. An alternative method created by Eliyahu M. Goldratt known as Critical Chain Method utilizes resource buffers, and monitors project progress and health by monitoring the consumption rate of the buffers rather than individual task performance of the schedule. This does not dispense with CPM, as if the assumption is that there are unlimited resources, CCM becomes perfectly aligned directly with CPM.

At the heart of this approach is the notion of "constraints" and is in fact a derivative of Goldratt's main management theory known as the "Theory of Constraints" (TOC) introduced in his very famous book The Goal: A Process of Ongoing Improvement published in 1984. As this Wikipedia except explains, "according to TOC, every organization has - at any given point in time - at least one constraint which limits the system's performance relative to its goal (see Liebig's law of the minimum). These constraints can be broadly classified as either an internal constraint or a market constraint. In order to manage the performance of the system, the constraint must be identified and managed correctly (according to the Five Focusing Steps below). Over time the constraint may change (e.g., because the previous constraint was managed successfully, or because of a changing environment) and the analysis starts anew."

It is a very common sense approach to identifying the constraints which prohibit a business from achieving its goal. Nearly every business pursuit has constraints that have to be mitigated in order to reach its goal, but what Goldratt's TOC provides is the application of scientific principles, logical reasoning and a systems based approach which is needed by very large organizations with complex organizational interdependencies. TOC breaks down this approach to 5 fundamental principles:

0. (Step Zero) Articulate the goal of the organization. Frequently, this is something like, "Make money now and in the future."

1. Identify the constraint (the thing that prevents the organization from obtaining more of the goal)

2. Decide how to exploit the constraint (make sure the constraint is doing things that the constraint uniquely does, and not doing things that it should not do)

3. Subordinate all other processes to above decision (align all other processes to the decision made above)

4. Elevate the constraint (if required, permanently increase capacity of the constraint; "buy more")

5. If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the constraint.

Though originally developed to streamline and optimize the operations of the manufacturing, project and supply chain industries, it has been utilized by service industries such as marketing, sales and finance. I need to study more on this topic, but my initial perspective is that this technique is more suited for environments with tangible outputs such as a manufacturing plant, but might be more harder to apply such reductionist rigor to a field such as marketing and sales, unless it was applied to measure a specific quantitative result such as for example, a marketing project to measure the conversion rate of a new campaign targeted to steal market share from competitor, and the constraints overcome to obtain that goal.

In any event, I definitely think this is a process improvement methodology that will profit from more study and investigation on my part.

Innovation Metrics

Very interesting blog on the principle of measuring innovation. We typically associate innovation as a highly creative, on the fly dynamic process that invokes the notion of a person with a light bulb going off in their heads, because they have just come across a major epiphany. The reality of course, is that it can take years of hard persistent work to reach a point where such an epiphany bears fruition. Read any history text or biography of historical geniuses such as Einstein, Edison, etc., and you will see this pattern throughout.

Much in the same way, the author of the blog positions the notion that companies need to apply this kind of historical archiving of innovative ideas, so that some kind of rigorous, quantitative metric could be applied to measure both the predictive likelihood of the ideas potential, tools and processes to apply to the idea so as to be realized, and quantitative measures to gauge its progress. Its a basic Input/Output model:

Input metrics

• Number of ideas generated
• Resources allocated to innovation - people and budget

Process Metrics

• Average time from idea approval to implementation
• Number of ideas approved and number implemented
• Stage-gate pass rates
• Value of the innovation pipeline

Output metrics

• Number of new products or services launched
• Revenue from new products or services
• ROI on innovation spend
• Market Perception
• Number of new customers

And of course, this has strong ties to project and product release and management cycles, as each of those ideas would typically be launched through a project/product development life cycle. In fact, that input, process and output technique is the very same technique advocated by PMI's PMBOK in it's Input, Tools & Techniques, and Output model for managing projects.

Some may argue that applying such rigor to innovation may stifle the creativity needed to generate such innovative ideas, but that is to misunderstand the purpose of these metrics, for as the blog states, "By choosing and applying a small number of metrics appropriate for your business you can add innovation to your balanced scorecard and give it the high level attention that it needs if you are to succeed".

Microsoft Project owns 80% of the IT PM space

This Projects@Work article suggest that Microsoft Project is the de facto leader in the marketplace for project management software:

Microsoft is "the de facto leader" in the North American IT project management software space, with 80 per cent of respondents to a recent survey by IT analyst firm Info-Tech Research Group indicating they rely on Microsoft Project to manage IT programs in their enterprise...

The 2008 Info-Tech study, which surveyed more than 250 senior IT managers in companies located in the U.S. and Canada, found that IT departments have few viable options to move away from Microsoft software. The closest competitor is CA Clarity, with a mere 1.3 per cent of organizations turning to their software for Project Management support.

"Most companies want to start out with a tool for managing basic requirements such as schedules, time/task reporting, and resource allocation," Colasanti said. "Microsoft's competitors in the project management software space promote their more advanced portfolio management tools, which is overkill for the some 75 per cent of companies that are not yet mature in their project management discipline. More advanced tools are daunting for these organizations since there is no process in place to support them."

That last sentence is the most telling, and is one for which I agree with, since you have to have a pretty mature process in place before you adopt such levels of sophistication in your choice of toolsets. But it's the classic "chicken and egg" problem, since you want to make sure the tool you purchase will have the necessary features available to implement a PPM system, but on the other hand, you may scare off and defeat the process of rolling out a PPM system if your tool is too complicated and advanced for your organization or is rolled out badly, which is typically the case.

But Microsoft as always, knows how to cater to mediocrity since as one of the PMs interviewed in the article sums up well, "I have never even seen another project planner. So really it's just been the tool that's been everywhere which I have then adopted." This is not meant as a pejorative statement against Microsoft or the PMs who use it, since given that Project is typically bundled with Office and has a similar look and feel to that suite of applications, it is natural for PMs to use it and is a testament to Microsoft's product placement and marketing strategy. Even then, MS Project's features and functionality has grown through each iteration, and there are even whole organizations devoted to the learning and use of MS Project since to use it effectively requires a fair learning curve.

Regardless, I think the best approach is to start with very basic features and gradually roll out more advanced capabilities in tandem with building out the processes, procedures and project management capabilities in an incremental and iterative fashion, as the article states, "since project management is an evolving discipline and it takes time for an organization to mature, vendors need tools that match this process evolution. Once an organization has matured its process, it will then look to that same vendor for a more advanced project management tool that includes portfolio management". Therefore, depending on the size of your organization and the future anticipated needs, it might be best to go with a more capable PPM software vendor such as Planview, Primavera, Clarity, etc. and start small and build up.

Whereas if you start with a more simple tool such as MS Project or Excel, it may be harder to move your organization away from it. I'm currently experiencing this with my own work to roll out Planview across my organization.

Scrum PPM: Agile principles applied to Project and Portfolio Management

Here's a good video on how to incorporate a Cost/Benefit Analysis (CBA) to an Agile development process:




As I have just recently acquired my ScrumMaster certification from a workshop presented by none other than the co-founder of Scrum, Jeff Sutherland, I am now trying to find a way to realize the full benefits of Agile/Scrum especially as it applies to fields outside of software development that it derived its roots from and is closely associated with.

One area in particular that I am especially interested in applying Scrum to is PPM and portfolio management and optimization in particular. I ran across this article on Scrum Alliance and it outlines the basics of what I have in mind:

Treating your project portfolio like a backlog of stories means you are able to say, “no” to projects earlier, releasing resources to other projects. That’s good; but what’s better is that, instead of a black or white world, where projects are being canceled or not, you have more options. Consider these scenarios.

A portfolio manager realizes after two iterations that Project A will not return the promised marketing forecasts. The project’s priority drops and its resources are freed for other more lucrative projects. The project’s achievements, though, are stored; the project has simply been moved into the agile portfolio—returned to the backlog, so to speak.

The originally proposed features list for Project B is 80 percent complete. The project is far beyond delivery date and the competition has announced an impending release whose features are similar to the ones that have been completed to date. The portfolio manager decides to stop the project

Project C is a proposal that initially sounded very promising and relatively easy. After only one iteration, though, reality has proven the feasibility study wrong. Rather than waste any more time, executive management decides to cancel the project and remove it from the agile portfolio entirely.

Notice how in all of these scenarios, there was no stigma attached to modifying, delaying, or canceling a project. “No” has lost its sting. Because the investment in each project was minimal, the cost of returning it to the backlog or changing its parameters was also minimal. That’s powerful. That’s agile.

Johanna Rothman, famed Agile practitioner and author of Manage It!: Your Guide to Modern, Pragmatic Project Management, states that when organizing an Agile portfolio, she asks these 4 basic questions:

1. How strategically important is this set of work?
2. Do all these things look like they'll fit into one iteration?
3. How does this iteration fit into all the releases we'd like to do?
4. Is there anything preventing us from completing a particular iteration? (Or is there a reason to order features in a particular order?)

When viewed from the lens of a traditional PPM point of view, question 1) asks you to prioritize the projects based on a company's strategic initiative, 2) is really asking whether you have the resource capacity to do the work, 3) is whether it will impact scope/requirements and 4) is whether there are any roadblocks (impediments in Scrum terms) that will effect the performance (or velocity in Scrum terms) of the portfolio.

The following figure from Lee Merkhofer, a well know practitioner in the field of decision analysis techniques for prioritizing portfolios provides a flow diagram that parallels the questions just outlined:


Interestingly, there is really little divergence from the questions and procedures outlined by the Agile and Traditionalist groups, except that the latter has a bit more formalisms in their terminology and process. In my mind, both movements have always adopted the notion that you would have to loop back into your process if scope changes occurred (which they almost always do), and the difference is that the Agile group have been more explicit about it and needed to create a new vernacular to describe their process so as to differentiate themselves from the waterfall movement. PMI in their upcoming 4th edition of the PMBOK seem to be trying to bridge this gap and is a topic I wrote about before.

The diagram below shows how easy it is to reconcile the two movements:


Regardless of where one stands in relation to these two movements, the most important factor is that effective PPM management is more than just the collection of status reporting of a group of projects for a specified date, but also forecasting the delivery time, scope and cost of those projects and how that will impact the overall business initiatives of the company. Without this capability, we are not able to take true portfolio decisions – such as reallocating investment from one project to another, or canceling underperforming projects – to maximize ROI.

But once an organization has realized and achieved such a state, the organization has moved beyond traditional PPM, and is now engaged in Portfolio and Investment Optimization (PIO) and would be looking to utilize such portfolios of investments to capture new markets and/or become a disruptive force in their industries. Traditional project management is typically concerned with what is known as the "triple constraints" of time, cost and scope, but an organization involved with PIO would be elevated to a new triple constraint of priority, capacity and objectives:


The need to balance the constraints of time, quality and scope to maintain the quality of the projects and portfolios would be elevated to the balancing of priority, capacity and objectives to maintain the performance and velocity of the portfolios and investments of the organization.

By adding the descriptive, empirically based framework of Agile/Scrum to the prescriptive, process based framework of the Waterfall/PMBOK we can have the best of both worlds: e.g., time tested and proven methods of traditional project management and the unadulterated transparency that exposes to everybody whether the best decisions relative to the business objectives are being taken given current information at the moment of decision and if not to go back and fix the problem through iteration.

By integrating and utilizing these practices on a consistent basis, would an organization be truly engaged with the kind of forecasting and trend analysis at the enterprise level required of a PPM system allowing it to build an optimized portfolio of projects and investments. At this level it could develop truly meaningful, time dependent models that would allow the organization to determine demand capacity, prioritization of important project investments, and shifting requirements of its total portfolio. This is the foundation of PPM that maximizes the efficiencies to obtain ROI.

PPM software vendor underdogs

Came across this interesting article discussing MGM Mirage's project to build an $8 billion city center, and is considered the largest private project ever done. What's most interesting to me is that they will be using a PPM solution from a little know vendor:

So when CityCenter project leaders had to select a project management system to help monitor what is believed to be the largest private development in U.S. history, they naturally settled on a proven software package that they were sure could support such a massive undertaking, right?...

By August 2005, Bodner and other project leaders were reviewing proposals from four software vendors, including Skire Inc., a little-known company in Menlo Park, Calif., that was pitching a hosted Web-based system. Bodner was impressed with the functionality of Skire's Unifier capital project and program management system. "With Skire's product, there wasn't any preconceived notion about how to do change management and cost reporting," says Bodner, who has 34 years of project management experience. Skire users "can dictate how [they] want this information recorded and reported,"...

Bodner's push to sell his partners on Skire began with MGM Mirage's IT organization, which he invited to grill Skire executives regarding the company's financial background and security provisions. After Skire completed a 20-page questionnaire, a team of MGM Mirage security experts tried unsuccessfully to hack into the hosted system. That exercise, along with supportive references from Skire customers who were using the change-control and cost-reporting functions, helped clinch the deal between the CityCenter project team and Skire in October 2005.

So despite the fact that there are a plethora of PPM solutions out there including many well known ones such as Planview, Primavera, CA Clarity, MS Project Server 2007, etc., there is still room for smaller, less well known companies such as Skire to capture one of the largest private projects to date. Perhaps the software market is not as saturated or a commodity as one might think.

Managing the twitter crowd

This very interesting article on Gantthead.com talks about how to manage the short attention spans of what I like to call the "Twitter" crowd. Twitter.com is a popular social networking site that allows people to send quick text messages to people either by web or SMS messaging, IM, etc. In other words, twits sent by Twits.

As the article points out:

The articles we read tend to be shorter, the demands on our time greater and the digital content we are interested in is packaged, targeted and delivered to us in quickly consumable and easily digestible packets.

What does this mean to the manager today? With so much of our everyday lives tailored to the “I-want-what-I-want-when-I-want-it” mentality, we need to change our management approaches slightly to accommodate the culture-induced inattentiveness of our team members.

I like the articles advocation of using the "two-minute drill" metaphor from football, where your forced into making quick decisions which means having the quarter back huddle very quickly (and sometimes not at all) and dispensing the plays out quickly and succinctly.

In my profession, the project manager would be the quarter back and as the article states:

As an antidote to on-demand attention spans, the two-minute drill technique can be used with stunning results by project managers and managers alike.

By crafting a focused, targeted and easily digestible plan, you are forcing yourself to edit out the fluff and become succinct. By limiting yourself to what can be communicated in two minutes, you are distilling your message to its salient points and removing the verbose filler that we all sometimes let creep in. You may love to hear yourself talk, but not everyone else does. The longer your talk, the more diluted your message becomes--and with that dilution goes its impact. Lost in a sea of disjointed ramblings is the point that was groping to be made.

Though I prefer speakers to dive into the details of particular topic especially if it interests me or if it is important, I have to confess to pontificating on topics that I happen to be leading a meeting on or conducting a training sessions on. But not everyone wants this level of detail, nor have similar interests, and given the short and ever shortening attention spans of people these days, I'll have to be mindful of adopting a more focused, sharp and succinct delivery of communications.

On the one hand, this is good since it keeps the topic focused and saves time, but on the other, there is the risk of glossing over important details and really, what time is being saved? Typically it is time that these Twitters waste surfing the web, talking on the phone and text messaging each other.

That's what scares me about this generation and having to manage them.

Bridging the gaps of Enterprise software

The following article on gantthead.com bemoans the gaps that occur when trying to roll out an Enterprise wide PPM solution, but could be applied to any ERP type roll out, whether SAP, Peoplesoft, etc. Basically, the gap is not properly preparing for and agreeing on the process and capabilities the tool is suppose to deliver:

But once push came to shove and the time came to actually use the software for the purpose that it was intended, what became very clear is that it didn’t support how projects were managed in the organization. Not that it couldn’t support how projects were managed…but how the software was implemented was not effective based upon where the organization was at the time.

The challenge here was that the organization didn’t really have a process of how it managed projects. There were experienced project managers with their own toolsets, approaches, processes and practices. There was some commonality in terms of template standards that were in place. But apart from compliance with the essential practices of the organization, how any one project was managed bore very little similarity to any other project. What was valued was that projects got done, not that a consistent approach was used in managing them. All well and good, and many might say that it’s the results that matter. However, when you are trying to manage multiple projects in a common information store in order to establish an integrated view of projects and resources, consistency counts for a lot...

Consistency may not be valued on a practical level, but when we expect everyone to use the same software and create any degree of value out of doing so, consistency is essential. If we’re not prepared to be consistent, implementing the software is likely a waste of time. And when we do implement the software, starting off with some basic capabilities and enhancing its use slowly is a far likelier pathway to success. As with so many other things in life, it’s not the size of the software that’s important, it’s how you use it.

This is the typical problem in all IT software roll outs, where you purchase a very fancy tool before you even really know what your going to use it for. It's an absurd logical fallacy, but for some reason, many if not all corporations follow this same illogical pattern.

For a simple example, its like a person purchasing an elaborate set of auto mechanic tools worth thousands of dollars, before even knowing what he/she is going to use the tools for: will they use it change the oil in their car periodically, or do they intend to rebuild classic cars for resale? For the former, it would be a complete waste of investment, and even for the latter, you'd probably want to make sure to what degree do you intend to rebuild classic cars? Do you think you will fix up and resell you old 84 Camero, or do you intend to pick something up from the junkyard and rebuild a car from the ground up?

These are the kinds of questions you'd want to ask yourself, yet curiously I don't really see these questions being asked prior to a company's decision to purchase or roll out a large scale enterprise software solution. Sometimes it just seems assumed you need one of these.

And from this article from InfoWorld, more enterprise PPM solutions seem like they are going to be purchased in the future, not less:

Data from Forrester Research shows that project-related investments consume about 18% of overall IT spending, and AMR Research reports more of its clients are inquiring about PPM and how it can help them avoid costs and improve project success rates. For instance, while 15% of some 230 clients asked the research firm about PPM directly, another 14% requested more information on ITIL and other best practice framework, which analysts say directly relates to PPM.

I'm leading and involved with a similar roll out, and though I may seem one sided and critical, the reality is that where we are at now, with increasingly fast pace of technological and business process innovations, an organization does not have the time to take all the considerations to be carefully deliberated on, and with the increasing ubiquity of technology in all our lives both business and personal, its hard not to want to immediately streamline your processes in a fancy toolset. In addition, with the increasing requirements of regulatory compliance, an organization typically needs all these data points captured in electronic form and in a database.

But stepping back and viewing our sometimes irrational decisions, is comical, disheartening and educational all at the same time.

8 components of managing Scope Creep

I discovered an excellent article over on Six Revisions on Feature Creep. It has direct relevancy to a project manager, since feature creep is really a form of scope creep for projects.

It outlines 8 basic components:

1. Accept that feature creep will happen.
2. Commit enough time to requirements-gathering.
3. Giving a hand might cost you your arm.
4. Be the devil’s advocate when changes are requested.
5. Be task-oriented, not vision-oriented.
6. Shed the “Customer is Always Right” mentality.
7. Research before committing.
8. Realize that feature creep is a two-way street.

All of these are excellent and very relevant points, but the a few of these stand out are 1, because though everyone involved in a project know that scope creep will be inevitable, we still seem to work under the assumption that we can nail it down in the planning phase. As the author states, "acknowledging this eventuality will allow you to be prepared when it finally rears it’s ugly code-retrofitting, design-wrecking head".

5 resonates with me, since I tend to be too big picture oriented and am always viewing my project in terms of the overall strategy of the company. Nothing wrong with this, but it does have the tendency to make me not as precise on the scope as I should be. "Be clear on what it is, exactly, you’re developing for them. Don’t promise a grand, exciting, but ambiguous/ambitious end result", states the author, and I couldn't agree more.

Finally, 6 is something I need to practice, as I'm too eager to please stakeholders and keep the project and the stakeholders in good terms. So "don’t give in to unwarranted requests and unreasonable timelines simply because you want to be on your employer’s good side. Don’t feel pressured to do something that isn’t in the job description or something you feel will lead to a less desirable end product".

Thus, as 4 states, you need to be steadfast and not "afraid to contradict unwise feature requests; providing well-formed reasons will assure them that you know your 'shizznit', and they may actually allow you to proceed as originally planned".

This article has done an excellent job of reminding me of doing my due diligence to avoid scope creep on a project I am currently managing, and I highly recommend it.

5 Portfolio Management Tips

Gantthead.com has a pretty good article about effectively implementing a PPM system titled "Effective Portfolio Management Implementation Tips". The article gives a pretty good rational for following 5 tactical tips with respect to rolling out a PPM solution:

Tactical Tip #1: Manage portfolio operations reviews using the PPM Tool.
By establishing a weekly or monthly process to update the tool, managers will encourage users to incorporate the PPM system into their daily, weekly or monthly routines. If the PPM solution is tracking project actual hours, users can update the project schedule in the tool daily. Implementation managers should emphasize the importance of using the tool to develop the operational reports required to manage the IT portfolio....

Tactical Tip #2: The project manager will only update the status in one system.
This tip may seem obvious given Tactical Tip #1, but organizations have been know to implement a PPM system only to ask the project manager to complete a new form or template with the exact same information. Instead of wasting the project manager’s time with redundant administrative tasks, encourage the PMOs to generate reports using the data the project manager updated in the PPM system. Managers want “one version of the truth” and populating data manually in two or more repositories further obscures accurate information.

Tactical Tip #3: Implement functionality in phases.
MS-Project integration, dashboard reporting, workflow, collaboration, Web-based change, issue and risk management all look incredibly attractive on the vendor’s demonstration system. Implementing all these features in a real-world environment and ensuring the data is kept up to date requires more than a technical implementation. Change management, training, organizational support all need to be in place to support a full PPM system....

Tactical Tip #4: One PPM System, One Project Status Report.
Project status reports tend to change depending on the target audience. Frequently, managers are asked to provide one status at the project or program level and then provide status in a different format for another targeted audience. Regardless, if the organization needs two different status reports, the data needs be maintained and updated in one system. If the project manager is required to enter data in two places, the PPM system hasn’t helped the PM; instead it added to the PM workload....

Tactical Tip #5: Ensure the project teams have enough software licenses to use the solution.
Effective PPM solutions benefit from collaboration. If the user base is limited to just project managers, the solution quickly limits itself. Effective PPM implementations allow all project team members to enter risks, log potential changes requests, update issues and provide updates to the project schedule. If the user licenses are just licensed to the project managers, the PMs become a bottleneck for administrative updates. During contract negotiation, flexible user license arrangements can be built into the contract. If the tool doesn’t allow the entire project team to leverage the tool, it will quickly become a seldom used tool during project execution.

These tips are quite useful to me, as I am currently managing the roll out Planview Enterprise 9 throughout my organization, and these tips are quite useful to review. Particularly tip #3, as I feel it is very important to release incremental "pilots" of the eventual implementation in phased releases in a development environment.

This ensures no disruptions to the production environment, and allows test users to work with the prototype in a sandboxed environment. I highly recommend reviewing the article if you are in a similar situation.

PMBOK 4 going Agile?

The 4th edition of the PMBOK is coming out and a draft edition was made available for current PMP certified and non-certified experienced project managers to review and comment on it. A section that particularly interested me was Section 2.1.3-2:

An iterative relationship, where only one subset is planned at any given time and the planning for the next period is carried out as work progresses on the current deliverable. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research, but it can lead to rework and reduce the ability to provide long term planning or scope control for the project. It also entails having all of the project team members (e.g. designers, developers, etc.) available throughout the project.

This section was no doubt influenced by the Agile software development and project management movement. Though in all fairness, the PMBOK has acknowledged that many project would be better served using a more iterative approach in the form of progressive elaboration or "rolling wave planning" since the 2000 version, I believe.



This notion addresses the idea of planning near term work in detail and later work in less detail. Then as new details emerge, going back to the plans and updating them with the new data. This is common sense to those in the Agile community, yet it seems that many in the Agile community seem unaware that it has been in the PMBOK for the last 8 years since, unfortunately, many Agile evangelists choose to ignore these important principles in the PMBOK Guide.

At least in regard to PMI, they seem to have acknowledged the importance of a more iterative approach and seem to have made it more explicit in the upcomming 4th edition of the PMBOK, since as they state "for multi-phase projects, more than one phase-to-phase relationship could occur during different parts of a project".

Implications of a bad requirements-gathering process

A recent article in CIO magazine points out the chronic inability of companies to define requirements:

A new survey by IAG Consulting finds that among two-thirds of companies polled, it is "improbable" that an IT project will be considered an overall success, due to inadequately or improperly gathered business requirements.

Fifty percent of these companies' projects could be termed "runaways," marked by at least two of these three factors: Taking more than 180 percent of estimated time to be completed, going over 160 percent of the established budget, and delivering less than 70 percent of the desired capabilities.

The other 32 percent of the companies surveyed enjoy a "probable" chance of success for IT project, according to the study, which surveyed more than 100 midsized and Fortune 1000 companies in North America.

I agree with the article which mentions how most employees view requirements as a "document" instead of a process. Furthermore, the majority of the time most are forced to document for the sake of documenting leading to badly written requirements, which in some cases would have been better had they simply written a check list of items to implement.

The whole rational for getting requirements, are so that the stakeholders and end users can make sure they get what's required so that the IT solution being built fulfills their required needs. Much of the disconnect at least as I've experienced it, is that requirements are done in a vacuum by business users without input from knowledgeable IT staff members who could place some reality checks on the time frame for which those requested requirements can be delivered.

And visa versa, if the requirements are done by only IT staff they may build something technically sophisticated, but of no use to the business end user. The article quotes some statistics to back this notion up:

The damage was worst when non-IT business analysts were in charge of the requirements. Those projects came in at nearly double their budgets and took more than 245 percent of their allotted time, according to IAG.

When IT workers managed the requirements analysis, the results were only slightly better, with budget overruns at 163 percent and time at 172 percent.

The best results came when business and IT worked together on defining requirements. There, budgets ran an average of 143 percent and time, 159 percent.

Even when there is a close alignment with IT and business, projects still ran over budget and took longer than estimated, and I think much of this stems from companies not having adequate training and dedicated staff, as the article states, "companies should form a 'center of excellence' for business-requirements gathering managed by both IT and business employees". I agree.

Project management a job commodity?

As I've mentioned in a previous blog, there's this sentiment that IT and the work involved with building and maintaining it is becoming a growing commodity. Its not a view that I'm in complete disagreement with, since the very nature of IT is to streamline and automate many of the repetitive business tasks that need to get done, and paradoxically, if IT is managed properly, then it stands to reason that the work you just did to build the infrastructure would make the very job you have obsolete!

But the reality is that IT is still hard, and though there have been much improvements in terms of tools, skills and management of IT related tasks, there is still currently a high demand for high quality IT related skills sets. A Network World article lists the top 8 IT jobs for 2008:

1. Programming/application development
2. Project management
3. Help desk/technical support
4. Security
5. Data centers
6. Business knowledge
7. Networking
8. Telecommunications

As the article states, "as the U.S. economy wrestles with a weak housing market and record oil prices, demand for IT workers is on the rise". Go to any job board, and you will still see many listings for the kinds of jobs listed above and practically all paying competitive rates much higher than the average. This is especially the case for metropolitan areas such as LA. This is especially relevant and promising to me, since I make a living as a project manager for a health care company.

And its usually the case that a person who spent an earlier career in a highly technical field will usually move up into a management type position and that position will almost always be as a project manager. This is because to manage the kinds of projects that person used to work in, its usually best if she or he had hands-on knowledge of the technical work and showed some leadership abilities. In addition, many technical people will move into project management because there's this assumption that such a position is less likely to be outsourced, since the main factors in success in project management are good communication and people skills. These are the kinds of skills typically not thought of as being easily outsourced.

But this interesting blog by Terry Doerscher, who is the Chief Solutions Architect for Planview, a leader and major player in the EPM market space, concludes that project management is now a commodity skill set:

Gartner isn't saying that PM is going the way of the Dodo Bird as a discipline or skill set; to the contrary, they are saying it has/will essentially become commoditized as a common element of the general management repertoire — think more along the lines of gulls and starlings. I have to agree on that point.

Ten years ago — even five for many, project management was still a capability that most IT departments were struggling to formalize and develop. For the majority of the larger shops these days, not only is basic PM capability in place and mature, it is almost ubiquitous. Competency in project management fundamentals has become pretty much a prerequisite for hiring anyone at or above team lead. The PMBOK has replaced Catcher in the Rye on freshman reading lists and a PMP certification is as common as an iPhone at Starbucks. (Before we go on, let me point out that this shouldn't be construed as some kind of a derisive shot at PMI — it is more of a testament to the level of growth and acceptance they have attained over the years.)

While there is merit to his argument, only in that project management has become more visible and important especially in the IT industry, I hardly think the skill set is a commodity. When I think of a commodity, I usually think of something that's mass produced and cheap, because the process used to create or manufacture the good, product or service is highly predictable and repetitive. But like the PMBOK states, a project is a temporary endeavor typically engaged by a company or business to create a whole new product or service to gain a competitive edge, acquire market share quick, or in response to a competitor's hot new product. Because of competitive pressures and the fast paced, global economy, project are hardly done in a commodity like manner, and this is especially true of project done in IT. As this article from the Economist captures:

Big projects today are as likely to be built on software as they are on steel. But IT projects are no better at meeting budgets and deadlines. A £6 billion project to put the medical records of 50m Britons online by the end of this year is way over budget and has already been postponed by several months. In March, the FBI finally abandoned a $170m internal IT project, two years after problems with it had first surfaced. The Standish Group, a research firm which produces an influential annual evaluation of IT projects, judged that in 2004 only 29% of such projects “succeeded”, down from 34% in 2002. Cost over-runs averaged 56% of original budgets, and projects on average took 84% more time than originally scheduled.

While I think much progress will be made toward refining and formalizing the discipline of project management, I don't think it is a skill set that can or every will be labeled as a "commodity", but will rather become or should become a core competency of any company. The Economist article summarizes this well:

Some companies have gone so far as to become more like project co-ordinators than producers of goods or services. The “business-as-usual” bits of their operations have been outsourced, leaving them free to design and orchestrate new ideas. Nike, for instance, does not make shoes any more; it manages footwear projects. Coca-Cola, which hands most of the bottling and marketing of its drinks to others, is little more than a collection of projects, run by people it calls “orchestrators”. Germany's BMW treats each new car “platform”, which is the basis of new vehicle ranges, as a separate project. Meanwhile Capital One, a fast-growing American financial-services group, has a special team to handle its M&A “projects”. For all these firms, project management has become an important competitive tool. Some of them call it a core competence.

When a company reaches a maturity level with project management such as this, then IT becomes a not just another cost center, but rather a true enterprise wide strategic initiative.

The expanding scale and scope of Agile

Here's an informative webcast on the scalability of Agile development/project methodologies:



What's most informative about this video, is the underlying acknowledgement for the need to scale Agile methods to larger, even enterprise wide organizational levels. Much of the reason for the success of methodologies such as eXtreme and Scrum was that it was employed in mostly small, co-located teams, which allows for the facilitation of self-organization and governance, as well as close interaction with stakeholders.

But many projects and IT initiatives have expanded throughout the enterprise, which have caused the need to adopt a more centralized, process driven methodology. A recently published book, titled The Enterprise and Scrum is attempting to address this issue, and has had mixed reviews on Amazon and lukewarm acceptance within the Agile community, at least as I've seen it.

Likewise, the Project Management Institute specifically via the PMBOK, has been criticized for being too centralized and process heavy, and not being "Agile" enough. While good for industries such as defence, aerospace, construction and other large infrastructure projects, it is not agile enough for software, Internet and other fast paced high tech industries.

What I think will happen, or should happen, is a merging of techniques from process heavy methodologies such as PMBOK, CMMI, etc. with Agile, into a more flexible, adaptive methodology, that can still be systematically scaled and centralized as needed.

PMP Preparation - Part 3: PMP Prep Book Reviews

***UPDATED*** (10/03/2009) - Recommended books below have been updated for the 4th Edition of the PMBOK. Have reviewed books and original reviews still hold

I include myself as one of the people who followed the "deep" method in preparing for the PMP exam outline in Part 2, and the benefit is that I read pretty much all the most popular prep books out there in detail and some texts, several times. Hopefully, this will benefit the reader so that they can pick and choose the best book(s) based on how they want to prepare. Here's the list:

1. PMP in Depth, Second Edition: Project Management Professional Study Guide for the PMP Exam, by Paul Sanghera. ISBN: 159863996X






I highly recommend this book, and recommend you read this as an introductory text for the PMP. Unlike the other books out there, this one structures the material based on the 5 processes, instead of the knowledge areas. This facilitates a better understanding of the PMBOK material and in addition, is completely self contained.

2. Head First PMP: A Brain-Friendly Guide to Passing the Project Management Professional Exam, 2nd Ed., by Andrew Stellman and Jennifer Greene. ISBN: 0596801912






Innovative book that uses lots of quirky visuals and other non-traditional methods to make studying for the PMP less tedious. This helps to reinforce and better retain topics important from the PMBOK that would otherwise require grinding repetition to retain in a more traditional textbook.

May not be to everyone's taste, but for me, it helped break the tedium of studying the other more traditional prep books. I think it's best used in conjunction with another prep book, but the book is stand alone in that you don't have to reference the PMBOK to fully understand the text.

3. PMP Exam Prep, Sixth Edition: Rita's Course in a Book for Passing the PMP Exam, by Rita Mulcahy. ISBN: 1932735186






Probably the most well known of the prep books. The book is really focused on getting you to pass the exam, and really pushes memorizing and test taking techniques. Not as self contained as the above two text, as you are referred to the PMBOK quite often.

Personally I found the tone of her text too threatening, in that she makes the PMP exam sound harder then it is in my opinion. Also, the book seems best suited to be used in conjunction with her prep classes, rather than to be read by itself.

4. The PMP Exam: How to Pass On Your First Try , by Andy Crowe. ISBN: 0972967346






Like Sanghera's text, this is a good introductory book to read to ease your way into studying for the PMP, but unlike Sanghera's book, it is not self contained. Has to be read in conjunction with the PMBOK for full benefit. Also, found some of the ITTO listings to be incomplete and the explanations not too in-depth.

5. Achieve PMP Exam Success, 4th Edition: A Concise Study Guide for the Busy Project Manager (Paperback), by Margaret Y. Chu, Diane Altwies, and Edward Walker. ISBN: 1604270187






The book I used in this the PMI-LA class I took in Spring 2007 and the class I taught in Fall 2007. Found this best used in the class, and especially as a reviewthe last couple weeks before the exam. In fact, I used it extensively for that and also found the CD with sample questions extremely helpful.

6. A Guide to the Project Management Body of Knowledge, 4th Ed. (PMBOK Guides), by The Project Management Institute, ISBN: 1933890517






I think it goes without saying that if your going to take the PMP exam, you must have this reference text. About 80% of what is in the exam is in this text. If you join PMI, an electronic copy is sent to you, but having a hard copy is sometimes convinient especially if you want to read it straight through.

The following books, while not specifically geared to preparing you for the PMP exam can and will be quite helpful:

1. The Fast Forward MBA in Project Management, Third Edition, by Eric Verzuh. ISBN: 0470247894






Excellent introductory book on PM. Has good diagrams, graphs, checklists and notes.

Found the book to be structured to and around many of the core topics from the PMBOK, with good clear explanations of topics such as WBS, network diagrams, and organizational structures.

2. Information Technology Project Management (with Microsoft Project 2007 CD-ROM), by Kathy Schwalbe. ISBN: 0324786921






The book is structured by all 9 PMBOK knowledge areas, and while not specifically a PMP prep book, covers all the topics of the PMBOK and does so from an IT project management viewpoint.

Gives very detailed, though somewhat text bookish (is used as a college text on IT project management) definitions, discussion questions, exercises, and suggested readings of PM techniques and methodologies, and is great for seeing how one would use PMBOK-like techniques from an IT industry viewpoint. In addition, has many relevant and real-world case studies.

3. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 10th Ed., by Harold, Ph.D. Kerzner. ISBN: 0470278706






Probably the most comprehensive book on PM. The latest 9th edition was written with the PMP/PMBOK preparation in mind, and each chapter concludes with questions and answers.

Chapters 11-20 go into the heart of project management such as planning, scheduling, cost control, estimating, procurement and quality. These chapter are indeed "hard-core" project management tools and techniques that are systematically discussed in depth. But this is where much of the meat of project management is discussed and where all the major PMP exam subjects are covered. Particularly relevant are these chapters:

11 - Planning
12 - Network Scheduling Techniques
14 - Pricing and Estimating
15 - Cost Control
17 - Risk Management
19 - Contracts and Procurement
20 - Quality Management

Was told in the Spring 2007 class, that though considered the "Bible" (which it is!) on PM, that it is a big scary book. I read it from cover to cover, and did not find it to be so at all. Definitely easier to read then the PMBOK in my opinion!

PMP Preparation - Part 2: Methods and Techniques To Pass

I. 3 Methods to Pass

In my view, there are really three ways in which you can prepare for the PMP exam:

1. Deeply - going this way means you would allocate about 6-12 months prep time, utilize 4-8 reference sources (books, CD-ROMS, websites, etc.), and make sure you fully understand the PMBOK at and beyond the fundamental level and know where and how to apply this knowledge to various situations and problems, based on your past project management experience.
2. Cramming - cram for the exam in a 3-6 week time frame, use 1 PMP prep resource (the most popular of this is rita mulcahy's "PMP Exam Prep" which I will review in another post) and the PMBOK (if this is even read at all), and attend an expensive PMP Boot Camp that uses intense cram sessions, clever mnemonic memory schemes, and drilling of test simulation questions 1 week before the exam.
3. Medium - this technique should typically take 3-6 months, and would try to adopt the best of both techniques in a timely manner and based on one's learning abilities. For example, in months 1-3 you would read the PMBOK first to get an overview, then carefully read 2-3 prep books (or other resources) to ensure you understand the materials at a fundamental level and to make sure you look at more than 1 prep resource to cover an deficiencies it may have. In months 2-5, you would start to take intense notes, re-read the PMBOK to see how much better you understand it and make sure you have synthesized the material enough to be confident you will pass in a month or two. In the last month or couple weeks before the test, is where you would start focusing on how to pass the test specifically and utilize the techniques from the cram method.

In my view, the "medium" method is the best for most PMP candidates. It ensures you allow yourself adequate time to fully absorb and understand the fundamentals of what the PMBOK is trying to convey, as well as why knowing this would be important to pass the exam, which is almost everyone's goal. Then close to the exam, use all the cram tricks from the "cram" school of thought to tie up any loose ends and to get you mind set up and ready for the PMP exam that will be coming up.

Not only will doing it this way ensure you pass the exam, but will allow you to actually understand, retain and apply your hard earned knowledge to your daily professional project management career.

II. More PMP Prep Tips

The following are tips from a PMP prep class I taught in Fall of 2007 for PMI-LA, and I'm reprinting them here slightly modified and is valid as of 2007:

1. The exam is neither real hard, nor easy. Remember you only need 61% to pass, but it is definitely not a walk in the park to obtain that score. In general, it is better to over prepare, then under prepare but don't stress about so much that you burn yourself out!

2. The PMBOK is boring as heck to read, but from my research and own experience, I agree with the common consensus that you should read this at least 2-3 times. I would read it once to get a good overview, then read the study books recommended below and when you read it again, it will make more sense.

3. If there is one thing I would recommend above all else, is to really understand the 5 processes, 9 knowledge areas and the 44 individual processes that comprise it and know it inside out. But I DO NOT recommend memorizing these, but rather to have a deep understanding of how they work, inter-relate and drive a project from initiation to closing. The PMBOK as well as most of the test prep books and courses follow the knowledge area in this regard, but I would look at these from the perspective of the 5 processes of Initiation, Planning, Execution, Controlling/Monitoring, and Closing. This is because it, in my opinion, follows how a real project actually functions and makes it easier to understand, study and relate to.

4. Definitely do some practice exams. There are good online test sites that are quite affordable and have good test simulations. A good site is www.pmstudy.com. In addition, I took a class through PMI-LA and they used a book called "Achieve PMP" that came with a test bank CD that was more than sufficient. Don't waste too much money on these, for example, many people I know who I took the class with in Spring that also purchased the Rita FastTrack CD, felt it was a waste. Taking 4 full exams is sufficient, and any more may burn you out, stress you out, or confuse you. The Achieve CD is all I used and I passed quite comfortably. But if you need more, there are some good online resources both free and for pay that is more reasonable then Rita's $300 CD.

5. One good way of understanding the ITTOs (Input -> Tools and Techniques -> Output) is to write them out on flash cards, since 1) writing them out is an active way to study them as well as reinforcing the understanding process, and 2) is great at forcing you to see how I/Os are usually things like plans, change requests, corrective actions, etc., and tools and techniques are the analysis, methods, skills and systems used to feed inputs into outputs.

In Part 3, I will list books I read to prepare and reviews of each.

PMP Preparation - Part 1: Overview

Overview

According to the PMI Member Fact Sheet, as of June 2006 there are a total of 192,599 Project Management Professionals (PMP) and no doubt that number has increased quite a bit since that time. In the US and pretty much the rest of the world (with the exception of the UK and other European country who lean more towards Prince2), it has become a defacto standard as such to gauge the competency of a project manager for better or worse. There has been and still is great debate as to whether the certification truly measures project management competency, and even whether it is a true certification at all, in the sense a CPA certification is regarded as a necessary step to becoming an true accountant.

Aside from these ideological battles, from a practical point of view, it will benefit a project manager more than harm him/her to get it and for the investment of around $1,200-2500 I definitely think it is worth it. Many PM jobs highly recommend and even require this designation, and if that helps you get a better paying job then the investment is worth it in my opinion. In addition, the certification has recently acquired ISO certification which is a world wide standardizing body and is the first certification to acquire it, which should help solidify the certification's global as well as domestic standing.

As the title of the PMBOK suggests, it is a body of knowledge and not a specific process framework to follow, though it does outline guidelines that one could (and probably should) follow in developing a process within the typical project management processes of initiation, planning, execution, monitor/controlling, and closing that is advocated in the Guide. This is in contrast to the Prince2 certification that is popular in Europe. But what this suggests, is that the topics covered in the PMBOK which in turn influences the PMP, is quite vast and one would assume that there would and should be considerable investment of time and effort to study for it.

But in fact, some of recent PMP prep services that have cropped up due to the increasing popularity of this certification, would lead you to believe otherwise. As this article by Mark E. Mullaly, PMP states succinctly:

The worst offenders in PMP preparatory training are the boot camps that promise an intense, focused week of cramming and guarantee success in passing the exam. This is all well and good so far as getting a passing grade goes, but how well do we hold onto this information over time? If we were to write the exam again 12 months after the boot camp—or even two months later—would we remember sufficient information to pass with a comparable mark? Will we be able to demonstrate our ongoing understanding of the PMBOK? And if we can't, just what was the point in taking the exam in the first place?

This type of preparation emphasizes the "binge and purge" type cramming done by many high school and college students across the nation (which I have been guilty of in my college days!), and encourages rote memorization, clever memory triggering schemes and techniques to evaluate the questions and answers to look for clues to find the best answer.

This is in opposition to the ideal way you should study for the certification, as Mark states, is to "learn the fundamentals of the principles being taught and, through a relatively deep understanding, be able to apply them to different situations and problems". Of course I agree with this assertion and is in fact the way I studies for the exam. But I realize everyone has different goals, inclination for studying and retention, and most importantly, finding the time. For unlike the carefree high school and college days, everyone taking the PMP are working professionals and in a profession that typically leaves little free time.

In Part 2, I will go over three ways you can pass the exam as well as some specific test taking techniques.

Video Tutorial: Making a Gantt Chart with Excel

Another example of the rich bounties of the internet. An excellent tutorial I found on how to create a Gantt Chart with Excel:



A great way to create a quick and dirty Gantt chart, without having to go through the trouble of using a project management software tool like Microsoft Project.

Book Review of "The Rise of the Project Workforce"

In the summary to the book, it boldly states that "economically speaking, the world is flat again. Globalization, projectization, fragmentation of the enterprise—including outsourcing—and real-time collaboration across the planet have enabled companies to reduce costs, leverage a global talent pool, and execute challenging deliverables with a dispersed yet incredibly connected project workforce." Integrating the popular notion of "flat world economics" made famous by Thomas Friedman in his bestselling book, "The World Is Flat: A Brief History of the Twenty-First Century", Melik outlines and develops what is basically an Internet based, online workflow system that could be used to manage a mobile, project based workforce.

This is important to keep in mind, because after reading the preface, perusing the table of contents and the general impression the book and its title invoked in me, gave me the impression the book was going to be written and themed in a similar vein as Friedman's book, but focused on the project workforce aspect. Instead, the majority of the book reads like a software requirements specification with bulleted lists, flowcharts, charts, wireframes, and constant allusions to the implications of a "flat" world, which by now has become a platitude.

In all fairness, the system he outlines in his text if it could be implemented in its entirety and most importantly, gain full cultural adoption and buy-in by the organization that implements it, would be an excellent system. The key to this system, which I'm in complete agreement with, is the need to automate the everyday workflow processes throughout the enterprise, such as time sheets, T&E expenses, billing, invoicing, etc. Furthermore, as Melik acknowledges, these processes need to be aligned with regulatory requirements and compliance, especially as he notes in Chapters 4 and 5 with SOX, labor laws, and contracts. This adherence to regulatory requirements and compliance, while simultaneously keeping agile, adaptive and responsive to the fast paced realities of the flat world is where it will be most difficult for companies. I'm currently with a company experiencing this very painful situation.

The book acknowledges that it would be unrealistic to convert to a enterprise level, Project Management Workforce overnight as outlined in the book, and advocates a sound approach of phased implementations that incorporates user adoption and company deployment incrementally. The final chapter gives a good example of the kind of business case for building company adoption, and Melik provides a step-by-step illustration of building a business case, with a fairly comprehensive table identifying stakeholders and the kind of issues and concerns each would address.

Now to the weakness of the book.

First, I would have liked more elaborations into the problems you would encounter trying to implement the Project Management Workforce in the real world, because the majority of companies have yet to embrace the "Hollywood Model" of bringing together the best human resources necessary for a project, then disbanding and forming other teams to other projects. Most companies are still struggling endless to hire the right talent for the right position. Typically, they will over hire when the demand is high, then lay off when they need to show quarterly profits to their shareholders. In addition, most companies have yet to even embrace implementing a sound project management system and processes within their organizations. The notion of a PMO has just recently come on, and the ones who have, have yet to implement it properly! How hard would it be to have such companies, which are the majority, to embrace such a radical transformation? Some real world case studies would have helped.

Second, the first part of the book elaborates on the notion as mentioned earlier about the emergence of the flat world and its implications on the global economy, quoting luminaries such as Thomas Friedman, Tom Peters, Andy Grove, etc. as a way to heighten the importance of the rest of the book and its system and to add a cutting edge legitimacy to its projectized workforce system. Not that such issues are not important, but the fact that these ideologies have already been regurgitated in industry trade magazines related to IT for the past decade or so ad nauseum, and the way Melik constantly sprinkles "flat worldness" throughout the book, make the notion trite and kinda of annoying to see repeated throughout the text. The project workforce system he outlines in this text would be a pretty good one, but there is nothing earth shattering about it and the majority of the book reads like a functional specification for a system the author is no doubt selling (The company selling the system is called Tenrox). Nothing wrong with that, but I felt hyping up the system using Friedman's ideology made the book promise more than it delivered.

In conclusion, this book was a very useful read and in fact, helped me to write a comparative proposal of two enterprise portfolio management system my current company is looking to adopt, by giving me some additional guidelines on what a good enterprise project portfolio system would have and the features to look for. But I feel it promised more insights and elaborations into "The Rise of the Project Workforce" ala Friedman's flat worldness then it delivered. Had it just stuck to outlining the functional specifications of a project workforce system, my expectation would have been more in check, but I have to admit the marketing of the book may have influenced me more to buy it, so in that regard it was well done.

Rich Schefren's Business Building Presentation

Watched this interesting video on how to grow your business:



Initially I thought the presentation was going to be another "get rich quick" infomercial, but instead found a pretty engaging presentation on the pitfalls of trying to do too much of the work in running an online business. This of course, is applicable to on an offline business such as brick and mortar retail or other direct customer service business as well.

Much of the topics Rich covers were already covered quite well by the likes of authors such as Michael Gerber's "The E-Myth Revisited", a book I read some years ago which helped me tremendously to increase sales and profit while simultaneously cutting down my hands-on work load. The section in the video where he discusses the 3 archetypes of Technician vs Business Owner vs Entrepreneur comes straight out of Gerber's text.

My criticism of his presentation is the fact that you can only start delegating work and expanding your business AFTER you start becoming profitable and not from the first day you launch your business which is the impression Rich gives you in his talk. In all my business ventures I had to put in long, long hours and considerable work initially and only when I was able to achieve good revenue, sales and most important profits, was I able to start hiring people and delegating. You'll either need to start off with lots of cash initially or wait and build your business up first.

But the most interesting part of the talk was when Rich discussed the importance of project management skills for the business owner and entrepreneur. I'm currently studying for my Project Management Professional certification and it dawned on me in my studies, that much of the PM processes would have been helpful for many of the projects I engaged in such as store remodeling, marketing initiatives, and especially when I was building out two of the businesses I built from the ground up. That if anything is a major project!

This interesting series of blogs discusses the very same thing.

Japanese Origins of SCRUM

I'm going to be giving a presentation tomorrow to my work colleagues on the origins, concepts and philosophy of the agile project framework called Scrum. As I am currently taking weekend classes as well as self studying for the PMP certification exam, the whole topic of project management has been on my mind quite a bit. Studying the traditional project management methodology of PMI in conjunction with research into Scrum for my presentation, has been an interesting study into the contrasting views with respect to project management from both sides.

This is not to say that either is right or wrong, or better than the other, but one is geared toward the dynamic and ever changing nature of software development [Scrum], whereas the other is a general framework for ALL kinds of project management endeavors. A blog for a book I just purchased, called "Head First PMP" acknowledges this, as they state "the PMBOK wasn’t written specifically for developers. A lot of projects that use the PMBOK processes and principles are things that you can’t do iteratively — like, say, highway construction or building a skyscraper... These are things that Agile doesn’t address because they’re just out of its scope."

The most interesting thing that though, that was revealed in my research into Scrum, was a reference to a paper by Hirotaka Takeuchi and Ikujiro Nonaka titled "The New New Product Development Game" which was referenced in the original book by Ken Schwaber titled quite appropriately "Agile Software Development with SCRUM". Published in the Harvard Business Review in 1986 it was a landmark paper and had many ideas in it that are now quite fashionable both in Agile project management and the general business landscape as well.

On the very first page is where the Scrum metaphor is defined as "a holistic or 'rugby' approach — where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements." But to simple assign this paper as the backdrop for how Scrum got it's metaphorical name, is to do a disservice to a short paper with some very profound ideas on management.

They highlight 6 main aspects to their management framework, which include the following:

1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

Any one of these topics could be a whole research thesis on their own, but they are at pains to emphasize that all these ideas must be taken as a whole and have full involvement from both the implementors and management at all levels. This is in agreement with the Agile community, especially with its emphasis on customer involvement since without their deep involvement and commitment, the whole notion of phased deliverables would not be possible.

I like Takeuchi and Nonaka's very modern ideas of employee autonomy and self transcendence that is achieved with self organizing teams. As they state "the project teams appear to be absorbed in a never-ending quest for 'the limit.' Starting with the guidelines set forth by top management, they begin to establish their own goals and keep on elevating them throughout the development process. By pursuing what appear at first to be contradictory goals, they devise ways to override the status quo and make the big discovery."

There are many other modern ideas such as giving employees an allocated time away from work to pursue independent research much like Google does today. The site 3M at the time who "encourages engineers to devote 15% of their company time to pursuing their 'dream.'" I would definitely appreciate my company encouraging such a thing!

I especially think their ideas of "multileaning" or what we would now call "cross functional" teams is a pretty important idea. There's a problem especially in the technical fields such as software development, where developers can get compartmentalized into a specific role and tagged as being the "Java guy/gal" or "DB guy/gal" and pretty much do nothing but that. This not only leads to burn out, but also keeps them aloof and completely ignorant of what other team members are doing. This is not to say that Designers should start coding C# or Business Analyst to build web pages, but using something like pair-programming with pairs from different departments would allow teams to better understand and appreciate what the other members do as well as picking up and possibly taking on a new skill set they might otherwise have not know they had an interest in.

In the final paragraph, they conclude "multinationals must achieve speed and flexibility in developing products; to do so requires the use of a dynamic process involving much reliance on trial and error and learning by doing. What we need today is constant innovation in a world of constant change." This was stated more than 20 years ago, but is more relevant today and will be so for the foreseeable future. It's has been both enlightening as well as a little sad that many companies then and today have yet to come to grips with this.

I highly recommend getting a copy of this paper and referring to it periodically if you are in involved in project management or any kind of business for that matter.