April 2009 Archives

Trust--backed by skilled developers--is the core element of any Agile methodology. Within the project team, the trust is relatively short term and the model is trust, but validate.

The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership.
 
Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time.
 
The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt.
 
An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end."
 
With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches:

We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value.

We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way.
 
In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline.
 
To be continued ...

Editor's Note: This post is part of a continuing discussion on Agile. View Lynda's recent entries.
 

Green IT projects may be in for a big push in the United States thanks to the country's newly appointed CTO.

In May 2008 Aneesh Chopra, then the secretary of technology for the state of Virginia, USA, told Government Technology magazine:

"Data centers are the energy hogs of the 21st century, and if we all believe we need to have renewable energy and energy independence in this country, those of us in the IT community must step up and acknowledge that we are net consumers in a significant way."

Sounds good--but will he really get people to hear the message?

Sivasailam (Siva) Sankar, PMP, president of the PMI Government Specific Interest Group, says U.S. President Barack Obama has made the creation of a transparent and connected democracy one of the key agenda items.

"The administration has already defined several key priorities, like the use of cutting-edge technologies to create a new level of transparency and improve the exchange of information between federal government and citizens, protect [networks], deploy broadband in every community, lower healthcare costs by investing in electronic information technology systems ... just to name a few."

Siva says the CTO's role is to promote technological innovation and develop national strategies for using advanced technologies to transform economy and society.

"There will be many technology projects initiated to satisfy the administration's core initiatives. Effective project management is vital for the success of the projects to ensure they're completed on time, on budget as well as utilizing public funds in an appropriate manner. I expect that the federal government would place a large emphasis on project management processes. I would also hope that effective portfolio management and governance processes will be implemented as well."

Siva says the appointment of Mr. Chopra is fitting because he has provided significant leadership as secretary of technology for Virginia in many forward-looking initiatives.

"He has practical experience in championing and providing high-level leadership to several high-tech projects."
 
 

Risk exists at all times. The less planning we do for it, the higher the chance of failure or uncertainty of results.

I am a strong believer in integration. Therefore, risk management must be an integral part of any organization's project management methodology.

Risks are generally identified, assessed and quantified. Risk is then monitored until it is no longer a risk or to ensure that any events identified as a risk do not actually go unanswered. That's where risk response comes into the picture.

Response to risks comes in the form of:

-    Acceptance
-    Rejection
-    Mitigation

Organizations must ensure they:

-    Identify key risk-management processes to map them out to the organization's processes for project delivery
-    Identify risk factors (i.e., elements that cause probability of risk occurrence to increase)
-    Standardize risk identification, assessment and quantification, and documentation across the organization

Think of it this way: Risk equals money. It's the amount of money we are going to spend (or not spend) on either activity A or B. If we identify a risk of executing activity A for a price of X, but have a moderate to high level of confidence in success of this activity, we may choose to forgo doing anything else or delay the activity to remove or reduce the risks.

If risks end up being realized and we end up facing the results of it, the cost of it would be linked to loss of revenue and added support to resolve the issue that was created by unresolved (but accepted) risk.

And if it is less expensive for an organization to actually accept the risk and deal with its impacts rather than continuously applying resources to making things perfect, then the justification of taking risk from financial standpoint can be very convincing.

How do you work with risk?

Experts on the assassination of U.S. President John F. Kennedy have come to a couple of conclusions: 1) the Warren Commission got it right and 2) many people have a hard time accepting that such a monumental, history-changing act wasn't the result of a massive, expensive, difficult-to-execute conspiracy.

So, when I started writing about how earned value management systems (EVMS) can accurately predict the future with some simple calculations, I received some responses that expressed varying levels of incredulity. It simply goes against intuition that an information element as important as at-completion project costs could quickly and easily fall out of an EVMS.

But since I've already firmly ensconced myself at the end of this limb, let me take it a step further: The estimate at completion (EAC)--the brass ring of management information systems--can be calculated without a baseline, a work breakdown structure or a formal change-control process--none of what we've been told are essential parts of an acceptable EVMS. None. Nada. Zilch.

Now, I'm well-aware that the previous sentence is the metaphorical equivalent of pulling the pin on a grenade and rolling onto the floor of a conference room full of EVMS experts, but I can explain.

The traditional formula for calculating an EAC (EAC = BAC/CPI) can be algebraically reduced to dividing cumulative actual costs by cumulative percent complete. That's right, we're talking two date elements, easily collected. And the resulting information is far, far more accurate than anything that the general ledger can produce. It's also much more accurate (and faster and easier) than re-estimating the remaining work and adding that to cumulative actual costs.

In fact, it's so much more accurate, faster and easier than any competing information stream, that I'm frankly flummoxed that the calculated EAC isn't the centerpiece of EVMS use everywhere.

I can't wait to see the responses to this one.

In the book Thinkertoys, author Michael Michalko says: "To get original ideas, you need to be able to look at the same information everyone else does and organize it into a new and different pattern. This is active thinking."

What can a project manager do when he or she needs to generate new problem-solving--or any really--ideas? Try SCAMPER, which Mr. Michalko calls "a checklist of idea-spurring questions":

•    Substitute some part, activity, or operation.
•    Combine the product/process/service with something else.
•    Adapt something to it.
•    Modify or Magnify it.
•    Put in to some other use.
•    Eliminate something.
•    Reverse or Rearrange it.

Consider a meeting I had with customers who posed the challenge: "How can we improve the existing document release process?" First, we went through and identified all of the sub-processes (request change, review request, create/modify document, verify/validate document, upload document to asset library and publish document.)

Using the "create/modify document" sub-process as an example, let's use SCAMPER to ask the following:

•    What activities can we substitute within the existing sub-process?
•    How can we combine "create/modify document" with some other sub-process to improve efficiency and accuracy?
•    What can we adapt or reuse from another "create/modify document" sub-process used by other business units?
•    How can we modify the way "create/modify document" sub-process is conducted?
•    What can we magnify or add to the "create/modify document" sub-process?
•    How can we put "create/modify document" process to other uses?
•    What can we eliminate from the way we "create/modify document?"
•    What is the reverse of "create/modify document" sub-process?

With more ideas generated, a project manager has more options to explore. That is why I am always looking for tools. How do you generate your ideas?

Organizations that have a project management office (PMO) show they are moving toward a centralized management of project resources and strategic alignment to business goals.

But I find a certain level of readiness has to exist in an organization for it to create the platform for a worthwhile and cost-effective PMO--the type of PMO that contributes to the business not by simply being an extension that offers extra resources, but that works and evolves with the business.

There are key issues in organizations that usually hinder this:

•    Senior teams do not understand the PMO or its purpose
•    Senior management teams do not understand what project management is all about and how it can help them lower the costs of implementing projects
•    The PMO is viewed as something you install without careful and business-aligned planning

In my mind, PMO implementation must be viewed and managed as a project. A company should know why it's seeking to implement a PMO in their organization, what business issues it's trying to fix and what inefficiencies it's trying to improve.

A company has to consider:

1.    Organizational Readiness
Organizational processes will require changes to ensure the process flows into and out of the PMO are integrated into the organization.
2.    Cultural Readiness
The organization has to assess its readiness based on current resource pools, whether the resources can be migrated to PMO teams, and how other members of community will be able to align with PMO requirements based on their knowledge, experience, skills and mindset.
3.    Strategic Alignment
The goal is not just to have another department, but to have a team of people agile enough to act quickly and in a focused manner. And planning of the PMO has to include reasons that align with direct impacts on strategic goals of the organization.

The Richmond Oval is already open for pre-Olympic events. The project came in under budget and on time--and it's already attracting attention.

Greg Scott, director of the City of Richmond, British Columbia, Canada's major projects office, said that the accomplishment, while phenomenal, has been taxing.

"[Information] we've been able to put on the Internet has certainly slowed down [requests]--or given media a thirst for more, I'm not sure which."

The team is now trying to solidify plans for what will become of the CAD$178 million facility after the games. The current thinking is that the site should be transformed into a multi-use facility for events including track, badminton, volleyball, basketball, gymnastics, special events and more.

Mr. Scott encourages project managers working on Olympic venues to keep the community's post-games needs in mind.

"If you do that and say that the Olympics--while very important--are the secondary function of the facility, you'll come out on a very successful note," he says.

Editor's Note: For more on the Richmond Oval and other 2010 Winter Olympics projects, visit PMI.org/features. And look for our next installment of the Project to Watch series in May.

Over the last week or so, there seems to have been a flurry of activity in the blogosphere discussing Agile and waterfall software development, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and project management. This is an important debate.

A letter in the Feedback section of the March PM Network said Agile is not a project management methodology--I agree. Waterfall and various forms of Agile are definitely software development methodologies, not project management methodologies.

However, we can learn a lot with an open dialogue in both directions.

One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong.

Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development.

Another misconception is that any new software development is automatically a project. Projects are temporary endeavors--this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work.

With these misconceptions cleared, there seem to be three key areas for discussion. (Your comments will be welcome leading into some future blogs.)

What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts:

•    The need for a much lighter "touch" managing an Agile project
•    The need for a higher level of trust in managing Agile teams
•    The need for robust change management and configuration management to track the evolution of the Agile project
•    The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including:

•    The need to trust knowledge workers more than manual workers
•    Success measured by customer satisfaction rather than quantitative outputs
•    The need to keep the client involved

What triggers the choice between operational maintenance and development versus projects and waterfall versus Agile.

More later.

My earlier post, Our Biggest Unused Weapon, posited that the ability of even a basic earned value management system (EVMS) to predict when a project will be complete and how much it will cost at completion is unparalleled in the management information system world. But I also argued it was being under-used by most practitioners.

William Goelkel, PMP, responded with:

"EVM can lead us to make bad decisions, or forecasts, when the standard against which we measure everything is the plan we baselined at the point in the project's life cycle when we were most ignorant of its requirements."

And

"I'm not convinced a calculated EAC [estimate at completion] as you described is always useful."

I'd like to further my arguments to the contrary while responding to Mr. Goelkel's thoughtful comment.

Mr. Goelkel's main example concerns software projects, where "goals change and our understanding of the users' needs evolves." Either this understanding evolution is captured formally and introduced into the baseline, or it is not. If it is, then there's no problem. If it is not, then we have scope creep, the most pernicious attribute of managing projects.

Even so, EVMS have a remarkable ability to predict the future, even when the baseline has been turned to rubber.

Say you had a US$100,000 project, but "evolving" customer expectations will end up costing the contractor double that, or US$200,000. At the point that the project should be half-done (cumulative budget = US$50,000, and actual costs are at the same level) the task leader assesses that she is only 25 percent done. The calculated EAC will instantly indicate the real EAC of US$200,000, allowing for either elimination of the scope creep or a request for more money.

For a more real-world example, try to find a project that (impishly) has a "Project Managers' EAC" column right next to the calculated EAC in their cost performance reports.

Ninety-nine times out of 100, the project manager's version is lower than the calculated one and less accurate. It's like clockwork.

In my next post, I'd like to tackle how project management trends in the software world--like scrum or Agile--are actually attempts to accommodate the rampant scope creep that so often afflicts those projects.

For now, I'd like to hear what other EV practitioners have to say. I'd also like to thank William Goelkel for this discussion.

For project managers out of work or just looking to change gigs, the recession and job cutbacks have made the competition tough. John Thorpe, managing director of Arras People, a project management recruiting firm in London, England, offers some tips for landing your dream job.

1. Focus on you, not your projects. Many people make the mistake of ticking off all their successful projects rather than talking about how they contributed to that success. "People are interested in what you did," he says. "You could have been serving coffee on that project. But if you made the difference in a project's outcome, be loud and proud about it."

2. Experience trumps training. Hiring managers are most interested in a proven track record. Mr. Thorpe suggests you put project experience front and center.

3. Market yourself. Your résumé is your sales literature and you have to sell your experience and education in a way that speaks to the person doing the hiring. "A generic CV is not going give you the best chance, particularly in this economy when hiring is tighter and roles are much more specific," Mr. Thorpe says. He suggests tweaking your résumé for each job, emphasizing your experience in a way that specifically relates to the position you are applying for.

4. Keep it short and sweet. Recruiters have hundreds of résumés to sort through. If yours is 17 pages long, they're likely to pass it by. "You have to grab their attention in the first half of the page or you are not going to make the cut," he says.

5. Consider contract work. Many companies are opting for temporary employees to fill gaps in staff without making a long-term commitment. For those with the right skills, contract gigs can garner decent wages and help you get your foot in the door.

6. Go to networking events. A lot of jobs never even get advertised, so it pays to network. It's a time-consuming but necessary part of the search, he says. "Finding a job is a job. You need to work hard at it and commit yourself full time."

Want to know where the hotspots are even in a down market? We've got it covered PMI's Career Track in the May issue of PM Network. We will also have stories on making time for training and moving up the career ladder.

And in the 10 April issue of Community Post, PMI members can check out an article on how to highlight your credential when you are jobhunting.

I am currently delivering a master class on project-based organizations (PBOs) at the University of Technology Sydney, as part of a the school's PMI Global Accreditation Center accredited master's program.

Part of the class included a workshop discussion on key issues concerning the transformation of a traditional organization into a PBO.

Five issues impeding the transformation were:

1. Selling the PBO concept to senior management
2. Ensuring collaboration across all levels of the organization and empowering people in light of the traditional hierarchical structures of organizations
3. Dealing with the effects of the current economic downturn on implementation
4. Bridging the gap between corporate and business strategies
5. Measuring PBO maturity and determining when an acceptable level of transformation been reached

While we only had time to delve into issues one and two, I feel the conclusions are worth sharing.

-To sell the PBO concept to senior management, project managers should:
-Be convinced of the value of the PBO.
-Secure the support of a champion at the executive level.
-Educate people about the PBO.
-Find examples of successful PBOs.
-Understand top management concerns and speak their language.
-Stress benefits of flexibility and dynamism in turbulent environment.
-Be realistic in selling it--do not promise things that cannot be realized.
-Plant the seed and let it germinate--do not try to rush the process.
-Build on existing strengths and don't try to reinvent the wheel.
-Take into account existing organizational culture and structures.
-Pilot the system in business areas that are receptive to it.
-Implement PBO components one at a time but always keep the big picture in sight.
-Make sure you address perceived threats.

Use emotional intelligence.And in terms of collaboration and empowering people, our conclusions were:
-What works in theory may not necessarily work in practice.
-Hierarchical organizations are very efficient, PBOs enhance effectiveness.
-PBOs can add flexibility and opportunities of career development.
-PBOs focus on multiple stakeholders, whereas traditional organizations usually focus on shareholders, so motivation of staff can be increased in PBO.
-Often in traditional organizations, career advancement is based on conformity. In PBOs, advancement should be based more on capability and innovativeness
-The PBO encourages feedback and learning,
-Bureaucracy is rigid and kills initiative, while a PBO is evolving and encourages initiatives.