Agile Team Lead Role

The Agile PMBoK

Insights into Agile Software Release Management at Salesforce

Insights into the monthly software development rhythm at Salesforce.com which drives their three releases per year ...

Agile Governance Structures

World class IT organizations are both highly efficient and effective. To become more effective in the application of information technology to business success, governance of enterprise architecture must look forward to ensure that the tactical decisions will holistically integrate in the future. ...

... "It allows the organization to create new capabilities with long-term focus and to respond to changes in its environment. This aspect is about doing the right things. " ...

Via eBizQ: Building an Agile Enterprise

Agile Project Stakeholder Engagement

With its speed and frequency of product builds, agile projects can offer a more engaging stakeholder process through greater frequency of touch-points, faster incorporation of stakeholder feedback, and sustained engagement over the project lifecycle. ...

... "Agile methods, by definition provide improved engagement for these stakeholders using two simple mechanisms: visibility and frequency of delivery. Review your stakeholder engagement map. Have you got the right people involved? " ...

Via InfoQ: Project Stakeholder

Agile Next-Gen IT Project Managers

Latest research from Forrester notes that next-generation project managers have adapted to flexible, agile methods. ...

... "they need to be flexible and focused on business value; and they increasingly need to be familiar with Agile software development methodologies ... " ...

Via ITBusiness: Project manager skills

Platinum Projects Stay Funded

Credit Suisse CIO Karl Landert was recently appointed to the company's executive board and reports to the CEO. He shares insights into steering the IT ship using flexibility and agility in staffing, while ensuring that the highest priority / value projects in the portfolio remain properly funded. ...

... "By and large projects that are on our radar screen as prioritized -- or platinum projects, as we name them -- have not been affected. We have gone through the same process we go through every year, which is that the demand and appetite for new things is much higher than we are prepared to fund ... " ...

Via Wall Street & Technology: Credit Suisse CIO

Perspectives on Agile Scrum

Agile Cycle Time Reduction Boosted by Global Sourcing Model

Global delivery models and agile techniques converge to reduce the cycle time of IT projects. ...

... "Mr Ratnayake said in the case of a telecom client in Europe, the agile technology usage was instrumental in being able to shrink the cycle of an IT project from what would have been 12 months, to less than two months. " ...

Via Economic Times: Agile Techniques in Practice

Agile Scrum Primer

Quick primer on agile development ...

Agile Techniques Discussed

Agile Scope Management

Insurance company uses agile methods to limit scope of software requirements and then increases frequency of releases to build out the appropriate business capabilities, giving IT's customers an opportunity to iteratively describe their key requirements. ...

... "Keith Young, IT director at Standard Life, oversees approximately 500 programmers, and said the agile approach minimises the risk of an application not meeting business requirements. " ...

Via ComputerWeekly: Agile software development

PM Goes Radical on Agile

Project manager's view on agile methods ...

Agile Expertise Shared

PMO director and senior project manager share their experiences with agile project management methods. ...

Plan and Estimate using Agile

Agile techniques are not just for small projects. ...

Agile Scrum Concepts Discussed

Ken Schwaber, the original scrummaster, visits the Googleplex to discuss agile techniques. ...






The Agile Alliance

Enterprise Architecture Comes to Forefront

David Linthicum, an author and respected expert on integration, shares thoughts on the importance of a well-planned enterprise architecture and leveraging architects to develop a sustainable roadmap. ...

... "If investors hold management accountable for accounting irregularities and missed sales, then lost dollars around the ineffectiveness of IT can't be far behind. Thus, the ability to maintain effective and agile enterprise architecture is indeed a corporate responsibility ... " ...

Via InfoWorld: SOA

Google Project Manager Clip

Quick video insights from Google project manager ...

Agile starting to scale, but...

Here's a nice summary of the Agile 2007 conference:

...proposals and ideas delivered at Agile 2007 demonstrate that while agile is starting to scale, it still has along way to go before the methodology becomes robust enough for enterprise deployment.

Agile 2007 Roundup: Scaling to the Enterprise by Tony Baer 17 Aug 2007

Project Management Wisdom: PMThink Readers Speak

We recently asked PMThink readers to contribute the best project management advice they've even received. Here's the compiled list:

"Great organizations, especially those that do well over the long haul, are masters of the obvious and the mundane." - Bob Sutton, Harvard Business Online, May 4, 2007.
(contributed by PMThink blogger Garry Booker)

"Always remember, there is only us" - Alistair Cockburn, on collaboration instead of "us vs them", in Agile Software Development 2nd Ed.
(contributed by John Rusk)

It's about the people...not the processes or tasks. You treat your people right, they'll make sure the project is right.
(contributed by Eric Brown)

"When people don't care about a project they can find a 100 good ways to make it not work that aren't their fault"
(contributed by Jason Bates)

"Make sure you really need a collaboration/project management tool before you try to use one." Many times a PM or collab tool is overkill for something that you could have accomplished in a phone call, a single email or a single document.
(contributed by Isaac Garcia)

Although the PMBOK puts the statistic a little lower, experience shows that -- "100% of SUCCESSFUL project management is communication" (whether it is used for team building, coordination of activities, collection/ dissemination of data/metrics and status)
(contributed by Laurie)

I always try to balance the interest of the people. Always find out how you can make person "A" agree on an idea that contradicts his own idea.
(contributed by Randy, PMP)

"Your success is driven in large part by your ability to leverage the community you build around you."- Scott Allen and David Teten , authors, 'The Virtual Handshake'
(contributed by Jason Bates)

"Never take anything for granted, never assume that something is happening, check"
(contributed by Frederic Casagrande)

"If you can't measure it, you can't manage it"
(contributed by Lucas Rodriguez Cervera)

I also noticed that Frederic Casagrande (who, incidentally, won our drawing) has a great list of additional tips for project managers on his website...

1. You can't manage a Project on your own.
2. Never take anything for granted, never assume that something is happening, check.
3. Seek to understand before you seek to be understood.
4. Delegate and remember there is more than one way to complete the same task.
5. Allow the team to take responsibility for the tasks assigned to them.
6. Manage the sponsor and don't let them manage you, you own the project.
7. Be realistic with the expectations.
8. Everything is resolvable, it just may take time to find that solution. If something goes wrong, don't take it personally, it's not about life and death.
9. Look at the whole picture and keep the end in mind.
10. Taking a decision and moving forward is always preferable to indecision and delays.

Frederic runs a nice blog site, Digital Addictions, with some additional great advice. Check it out at: http://casagrande.blogs.com/english/ - Or, if you prefer it in French, visit: http://casagrande.blogs.com/

With all this good advice from our readers and colleagues, project managers can't go wrong.

Outcomes and Actions...Too simple?

Some of the feedback on my previous post, about a new and simpler definition of the word "project" has been that the definition may be too simple. How could something as complex as a major business project be defined by something as simple as "outcomes" and "actions?" My answer comes in five parts:
(1) Outcomes and actions can be combined in a staggering number of ways, not unlike the way protons, neutrons and electrons are combined to form matter. Consider Agile PM, where outcomes are defined by a backlog of user stories (with story points) and executed in fixed time bins (iterations). Consider how Agile actions are guided by daily stand-up meetings. Consider large government projects where interim outcomes are described in "work packages," are defined and refined into a complex performance measurement baseline (PMB), placed under tight change control, and tracked with various pre-defined earnings rules. Consider how outcomes include widely-agreed concepts of "deliverables" and "creating unique products, services or results." And yes, intended outcomes and next-actions help guide personal decisions as well. It is a very scalable definition of projects -- more scalable, in fact, than the traditional definition of a project.
(2) There is a lot of room for improvement, even in traditional projects, for how we define, control and track intended outcomes and how we translate those outcomes into front-line action. Consider how many projects have failed because day-to-day actions were not connected to clearly-defined intended outcomes. Not so simple, is it?
(3) It takes extra effort to decide if a project activity should be defined by its end state (outcome) or is simply a means of moving us forward (action). If we don't go this extra mile, we may create an amorphous and confusing froth of outcomes and actions that is a source of miscommunication and waste. Outcomes and actions should be distinct, yet linked. And that is far from simple to do.
(4) One of the things I've learned about outcomes and actions is that they are entirely different beasts. Outcomes are the realm of control. God bless order and structure. Outcomes need to be comprehensive and mutually-exclusive, which is not so simple to implement, but very important too. Actions will never be comprehensive and mutually-exclusive. Actions are the realm of knowledge worker freedom of choice (which is why they are knowledge workers). Actions are messy, but God bless the mess.
(5) In upcoming posts, I'll show how this definition helps with respect to the next great frontier in project management, which is Management by Project (MBP). This simple definition, although written by a personal productivity guru, has surprising power with a topic that is beyond the scope of the PMBOK Guide.
Is the outcome/action definition simple? Yes. But it explains and predicts a lot of things from personal management, to project management, to MBP.
/Garry

Project Methodologies: Keep 'Em Flexible

Time and time again, I've seen organizations spend months devising the perfect project management methodology, sometimes even building it into their EPM tools, only to find people complain that it slows them down and doesn't add much value.

In many cases, they're right. The problem is that not all projects require every step, and in many cases there are easier ways to accomplish what certain steps are meant to do. Another mistake many people make is forcing task dependencies into the project template, such that design cannot happen until planning is completed, and construction cannot occur until the design is approved, and so on.

While this may be true of some projects, on many others, work does not occur in a linear fashion. For instance, certain segments of a project can udergo development while other segments are still being planned. On agile IT projects, the feedback from prototypes and iterations will often dictate the design, and rightfully so.

When it comes to methodologies, frameworks, and templates, the most effective organizations use one or more of following approaches:

- A methodology and project schedule template that allows project managers the discretion of which steps to apply to their project.

- Multiple methodologies and templates for various types of work, with streamlined versions for smaller or more flexible efforts.

- A methodology that identifies which items are mandatory for all projects versus those that are at the project manager's discretion.

In project management, as in pretty much any field, one size does not fit all.

Software Requirements Specifications: The Right Way

There's a useful article on Developer.com by Aleksey Shevchekno on the proper way to create effective Software Requirements Specifications.

He discusses the importance of use cases, how to design use case scenarios, the proper structure of a Software Requirements Spec, and even the appropriate language to use. He also suggests making the spec technology-independent and recommends appropriate wording.

Even for those with Agile projects, where the requirements will evolve as prototypes and iterations are developed, it's a valuable exercise to go through. Read on...

Software Requirements Specifications: The Right Way

Agile Tipped?

Have agile methods for software development tipped yet? And, the survey says ...

... "There are two interesting observations about these results. First, although the majority of organizations are applying agile techniques on projects of 10 or fewer people, many are, in fact, trying agile on larger projects. " ...

Via Dr. Dobb's Journal: Agile Survey Results

BT IT Project Model

One way to increase inventory turns is to decrease the lot-size in the supply chain space. For IT, reducing project size can have a similar effect. BT takes this approach to increase project throughput. ...

... "No IT project at BT is allowed to last more than 90 days. Mott says: If you can't deliver it in 90 days, then we're not doing it. So you need to pull teams together for 90 days, then a new team needs to form for the next project. " ...

Via Building: Agile Approach

Project Forecasting and Uncertainty

Yesterday, I posted about the need to focus on time remaining, using a driving analogy. The premise was that, if we were traveling from Philadelphia to New York and we were at the New Jersey Turnpike entrance (and assuming arriving on time is a critical success factor), the best predictor of success would be to determine how much time remains on our trip.

But what if arriving on time were not the most pressing need? And what if we increased the uncertainty factor? Is "time remaining" still something we can and should monitor?

Let's take IT research projects, for example, which tend to carry great uncertainty. Using an agile approach, the team builds prototypes, and the deliverables get ever closer to "the truth" as the project progresses. If we used a fixed set of iterations, and/or fixed-time iterations, we still benefit from focusing on time remaining, possibly even more so. The only difference is, we're operating in increments.

And even if time is not the ultimate concern, any customer will still want to know "How long will it take before I see something of value?", and usually, "How much will it cost me?" These are the basic fundamentals of good customer service. We still need objectives and scope statements, even on agile projects. It's just that we recognize uncertainty more.

And speaking of uncertainty, proper preliminary research and planning can often help reduce it, and contingencies or buffers can help prepare for the unexpected. Piecemeal deliverables (iterations) can also help, as learnings can be applied to the next phase.

Getting Projects Off On the Right Foot: The Pre-Flight Checklist

Something you don't hear much about, but is a critical success factor for projects, is what I call the "pre-flight checklist." As projects are completed, not only is it important to review lessons learned, but it's vital to have a checklist that can be updated as a result. This checklist would be the first thing a project manager would look at upon undertaking a new project.

This is especially true for agile projects, where adjustments are constantly made based on user feedback. Of course, not everything would go on the checklist, but any item that could save time later on a future project is well worth adding. Why reinvent the wheel?

If warranted, there could even be a checklist for various types or categories of projects.

This checklist is different from a pre-project assessment (another underrated tool), where preset questions pertaining to objectives, risk, value, organizational alignment, and more, can be asked.

As the adage goes, projects fail at the beginning, not the end.

Agile Project Management: Mainstream at Last?

There's an excellent writeup on the LeadingAnswers blog site about the rise, fall, and rediscovery of Agile Project Management. I like the "Universal Lifecycle of New Technology" which outlines how ideas take flight, and then, after people inevitably misapply or overuse it, it fails, only to be resurrected successfully later with a slight twist.

I've seen this happen with a variety of non-technology processes and ideas as well, including TQM, Six Sigma, Critical Chain, PMOs, and---dare I say it---Project Management in general, all of which are currently in various stages of this lifecycle.

The article is well worth reading. For fans of Agile Project Management or those curious in the concepts, LeadingAnswers is a valuable site.

By the way, as a proponent of Geoffrey Moore's Crossing the Chasm book on marketing disruptive technology, I was also interested to see that the article has a link to a white paper titled, "Crossing the Agile Chasm."

LeadingAnswers: Leadership and Agile Project Management Blog: The Rise, Fall and Rediscovery of Agile Methods

Is Project Management Relevant?

Over the years, I've had discussions with software developers who question the need for project management. I've heard everything from "The developers are the only ones who really know what's needed anyway!" to "All the project managers do is slow things down and add unnecessary bureaucracy!" to "Why can't the the developers just work with the customer to give them what they need and avoid the middleman?"

The fact is, given the right developer and a fairly isolated project, all of these are valid statements. But many projects are much more complex than that. They involve multiple stakeholders with conflicting needs, offshore resources, multiple vendors, complex interrelationships with other activities and departments, and more. They frequently involve managing all of this against budget and schedule constraints.

Leading, facilitating, and managing all of these elements is where a good project manager can help. An effective project manager removes barriers for a team rather than adding barriers. Any activities that may appear like "nuisance work" to technicians, such as reporting time or percent complete against milestones, are often necessary to meet the project's schedule or budget constraints.

A good project manager will work with developers to determine the appropriate project approach, depending on the constraints and the level of uncertainty involved. Perhaps an agile approach is warranted, with learnings applied incrementally. Perhaps piecemeal deliverables can be achieved for quick wins and earlier value. A good project manager will also prepare management reports, conduct presentations, and deal with vendor issues.

Most of all, a good project manager will communicate to all parties throughout the project. Although some developers do indeed have the expertise to do all this, it distracts from the work they need to do.

This is not just a nuance of the software industry. The same holds true in any industry where technical or subject matter experts question the need for project management. Project management is a completely different skill set, necessarily so. It's geared toward leading people to achieve objectives. An organization can of course put the project manager in a better position to be successful by providing adequate tools, general principles, and minimal bureaucracy.

The article below offers clear and simple evidence of the importance of project management. It begins with the results of a 1999 study that showed that the number one reason companies stopped working with Internet design firms was not about their lack of creativity or high costs---it was about their inability to effectively manage a project.

Here's the article...

MB Journal Article Archives

Traditional vs. Agile Project Management: All You Need to Know

Here's the best article series I've seen to date comparing traditional "plan-driven" PMBOK practices to Agile "value-driven" approaches. It's a four-part series by Michele Sliger on StickyMinds.com.

Enjoy...

Column info : Relating PMBOK Practices to Agile Practices - Part 1 of 4

Agile Project Management: Everything You Need to Know

For those who have heard about the benefits of Agile Project Management, there's an excellent primer at Projects@Work, including the best graphic I've seen to date to illustrate the difference between Agile and Waterfall approaches.

There's practical advice on what Agile is and is not, along with 10 steps outlining how to try it out. Check it out...

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

Software Quality Assurance: Integration Testing ...

Rethink integration testing ... create an exciting process that engages developers and QA participants. Put the software product through an end-to-end process that exercises it from a user perspective. ...

... "On an iterative or Agile project, integration tests happen at the end of each iteration. But in all cases, developers need to convince themselves and others that the software really works before they feel comfortable releasing it. " ...

Software Quality Assurance: Integration Testing: Via Dr. Dobb's: Better, Stronger, Faster Integration Testing ...

Agile Project Leadership ...

Agile network sustains mission with election of new board members. I like the relentless focus on value and all of the core principles. Worth a quick check. It's valuable to anchor back to principles periodically. ...

... "Agile Project Leadership Network (APLN) New Officers and Board Members: The Agile Project Leadership Network (APLN), a partner non-profit organization focused on making people great project leaders by focusing on value, teams, context, customers, individuals and uncertainty also named several new officers to its roster. APLN was founded in 2004 by individuals active in writing about, practicing and evangelizing the movement toward fast, flexible, customer value-driven approaches to leading projects of many types. Although the organization is separate from the Agile Alliance, the group's aim is to work closely with the Agile Alliance to help them become better Project Leaders. " ...

Via Yahoo Finance: Agile Alliance and The Agile Project Leadership Network Announce New Board Members and Officers for 2006-2007 ...

IT Governance Meets Server Virtualization ...

Cassatt and NEC combine to deliver portfolio management for virtualization of servers aimed at the financial services industry. ...

... "Cassatt Corp., an innovator in providing enterprise software and services to enable agile IT infrastructures, and NEC Solutions (America), Inc., a premier provider of integrated solutions for the connected enterprise in North America, announced the immediate availability of a fast track IT Portfolio Management solution for server virtualization and consolidation. Express IT Portfolio Management (e-ITPM) is a joint solution from Cassatt and NEC that provides financial services customers with the ability to realize greater costs savings by combining IT governance initiatives with internal IT projects on virtualization and server consolidation. " ...

IT Governance Meets Server Virtualization: Via Cassatt Corporation: Cassatt and NEC Expand Partnership to Target Financial Services Customers: Joint solution combines NEC Solutions America IT Governance Practices with Cassatt's Server Virtualization Management and Consolidation Solution ...

Has Agile Development Lost its Way?

According to Steve McConnell, chief software engineer at Contrux and a pioneer in the "rapid development" movement, Agile development has fallen short in several areas, straying from its original focus and becoming overly process and tool centric.

I know the original intent behind Agile was to focus on rapid iterations and frequent communication, but I wouldn't be surprised to see it distorted by organizations that miss the point (or that use it as an excuse to forego risk management).

The Scrum approach seems to me to still maintain the right focus, but only the most forward-thinking companies have been bold enough to adopt it (and are reaping the rewards accordingly).

Another point McConnell made was that one size does not fit all. He's right on there. We need to adopt the right approach for the situation at hand.

For more on McConnell's insights, read on...

Agile programming has fallen short, conference attendees told - Computerworld

For Project Management State of the Art, Attend the PMI Research Conference 2006

At PMThink, we're committed to researching the latest methods in project management, portfolio management, and governance.

Whether it's Agile Scrum methods, more focus on conceptual phases, or the latest innovations in organizational leadership, we're always looking for new and better ways to manage projects.

One good way to find out the latest and greatest in the field is to attend the PMI Research Conference 2006, which will be held at the Centre Mont-Royal in Montreal on 16-19 July 2006. Between the speakers and the attendees, it should be quite informative. Registration begins March 1st.

Here's the info...

Research Conference 2006

Agile / Scrum Project Management: A Certain Future? ...

Gartner looks into crystal ball and makes prediction on the evolution of IT projects into, what sounds like, an agile / scrum project management model. ...

... "Demise of the IT project: And in this world, the 18-24 month project will be as dead as the dodo. Imagine a world, Austin invites, where we measure outcomes, not progress, against plans and look for continual process, like the move from the production line to the manufacturing cell. " ...

Agile / Scrum Project Management: A Certain Future?: Via MIS Magazine: Crystal ball-gazing ...

Microsoft on Scrum & Extreme Programming

One way Microsoft's development teams intend to deliver products to market faster is through the use of agile development methodologies, such as extreme programming and Scrum. You may have seen some of our many other blogs on Scrum.

David Treadwell, corporate vice president of the .Net Developer Platform group at Microsoft, said that while Microsoft welcomes the use of methodologies like Scrum, "we're not mandating them, but we're encouraging them..."

"The other is extreme programming—the concept where you might have two people working on a given piece of code and the idea is that two minds are better than one. Because you can find problems faster."

Scrum process can not only be used for developing applications, but also to test them for quality assurance sign-off.

Thanks to e-Week for the news. For more see:
Microsoft Lauds 'Scrum' Method for Software Projects

Why Projects are Late; The Top Six Reasons

Here are the top six reasons why projects are late and what we can do about it...

1) Unrealistic Deadlines - As we've reported here before, this is one of the most frequently overlooked reasons for late projects---and unfortunately, often the last thing people look at.

Solution: It's imperative for a project manager to defend the right plan and not give in to pressure to sacrifice good principles. If necessary, negotiate to time-box the project into multiple phases.

2) Customer/Partner Availability - I've seen numerous project managers over the years talk about the challenges they face keeping a project on schedule when they're waiting on a customer or business partner to do testing or sign off on some deliverable.

Solution: Set milestones, monitor progress, and raise an issue if the lack of availability will cause a delay. If necessary, negotiate a new project baseline---which may be quite appropriate if the customer and/or steering team agrees that a delay is acceptable.

3) Resource Availability - There's nothing worse than putting together a reasonable schedule only to have your key resources pulled off into different directions, but it happens more often than we care to admit.

Solution: Try to obtain full commitment up front for your resources' time. Even so, unexpected conflicts will happen. Same as #2 above, set milestones, monitor progress, and raise an issue if needed. Again, negotiation may be necessary, which can result in getting your resources back or in setting a new project baseline to accommodate the new priorities.

4) Uncertainty - Especially in the IT field, uncertainty is a given. At any time, unexpected circumstances may cause project delays.

Solution: Use rolling wave scheduling, planning the whole project from a high level, but only the nearest 90-day horizon in detail. Try agile approaches as well, aiming for prototypes and frequent iterations. Ideally, pilot the project, and aim for vertical rollouts (one group at a time). Build contingency into your schedule for known risks. Most of all, manage stakeholder expectations.

5) Management Decision - Sometimes, management makes a conscious decision to delay a project, either for strategic needs, changes in priorities, or any number of reasons.

Solution: If the delay is a management or customer decision, a new project baseline should be saved, with current metrics based on that. Note that it's also important to keep the original baseline, as that offers a different set of measures (mostly around organizational alignment).

6) Poor Estimates - Sometimes a project is late simply because tasks were underestimated or omitted from the schedule. Although this is not always the cause of project delays (and rarely the only cause), it tends to be the first one people look at.

Solution: Build experience and capture historical data by project category and activity. If the data isn't categorized it won't be useful. Create and maintain checklists of items to consider. Build project schedule templates. The most frequently overlooked areas in IT are: training, data-loading, cutover preparation, system network testing, adequate QA testing, and documentation.

Characteristics of Scrum Project Management

Scrum is an agile method for project management, first implemented by a team led by Jeff Sutherland at Easel Corporation in 1993.

Characteristics of scrum include:

• A living backlog of prioritised work to be done;
• Completion of a largely fixed set of backlog items in a series of short iterations or sprints;
• A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
• A brief planning session in which the backlog items for the sprint will be defined.
• A brief heartbeat retrospective, at which all team members reflect about the past sprint.

For more info see: http://en.wikipedia.org/wiki/Scrum_(in_management) or our many previous blogs on scrum.

Innovation in Project Management; A Lesson from Ford

Tom Peters blogged recently about Ford, Pixar and the new wave of innovation sweeping companies. Although he had a softer spot for what Pixar is doing, the main point was that innovation is the new world order. Operational excellence is out, as is short-term thinking and reactionary cost-cutting. Even GE is now all about innovation.

Just look at these enlightening statements in a recent announcement from Ford CEO, Bill Ford, announcing their renewed focus on innnovation...

Ford Motor Company stands for a far-sighted commitment to growth. We stand for a renewed focus on the customer. We stand for boundless innovation in every aspect of our business...

Here is what we will not stand for: incremental change, avoiding risk, thinking short-term, blocking innovation, tying our people's hands, defending procedures that don't make sense, and selling what we have instead of what the customer wants. In short, we will not stand for business as usual.

Going forward, our employee evaluations will include a section on innovation. We’re also going to design compensation plans that reward new thinking. And we’re going to create a way for employees to appeal a decision, even if they have an idea and the boss says no.

These are inspiring words. Don't be surprised to see this approach make its way into the project management field. Instead of taking a project charter and "executing well," enlightened project managers will encourage opportunity assessments, get their teams and management excited about new ideas and concepts (assuming they're not squashed), and attempt to try new methods.

We've been posting recently about Agile Scrum Project Management. That's just one example of something that's new and different, but will most likely not gain ground in traditional, conservative organizations.

Here's more from Bill Ford's presentation...

Innovation Acceleration: Innovation-Driven Vision: Ford Motor Company

Agile Scrum Project Management; Applicable to All Projects?

I just finished reading Agile Project Management with Scrum, by Ken Schwaber, and the case is most compelling.

As we've posted here, Scrum is all about daily communication and short 30-day iterations focused on business value. No doubt it's a change from traditional project management, but it takes a sensible, pragmatic approach. As the author points out, Scrum is about "the art of the possible" and especially shines when dealing with complex initiatives (which most IT projects are).

While the book is geared toward software development projects, I found myself asking if this approach would apply to other projects, such as implementing packaged software, or even non-IT projects. I think the answer is a definite "yes." However, the first round may take longer than 30 days, depending on the complexity of the configuration and a hundred other variables.

Suffice it to say that time-boxed iterations focused on delivering some level of pre-defined business value at each iteration is the right way to go for most projects, and certainly most IT projects. Phased deliverables offer earlier payback, quick wins, and allow the flexibility of changing course in future iterations. That sounds like a win-win to me!

Agile Software Vendor Nominated in Project Management Categories ...

... "Rally Software Development Corp., the leading on-demand provider of Agile software life cycle management solutions, announced it has been selected as a finalist for Software Development magazine's 16th Annual Jolt Product Excellence and Productivity Awards. Rally is a finalist for awards in both the Enterprise Project Management and Quality Project Management categories. " ...

Agile Software Vendor Nominated in Project Management Categories: Via Rally Software: Rally software development named finalist in two categories for the 16th annual jolt product excellence and productivity awards

Agile Project Management with Scrum

I have been wondering lately, what does agile really mean here?
This article says, Agile means responding to change - both technological change and changes in requirements perhaps due to customer demand and market opportunities.

It makes sense to me that this would be needed. The world is spinning much faster now and people expect content on the web, for example, to be relevant.

How does this differ from typical PM approaches? It has an answer there too...
-----
More traditional project management "command and control" approaches assume the relationship between the inputs and outputs of a software development process are stable and predictable and that the schedule of outputs will still be relevant by the time they appear. Scrum accepts the fact that things are going to change and takes an empirical approach.

In Scrum work is delivered in monthly "sprints". Each sprint delivers a single, usable piece of work called the "product increment". This product increment is immediately available for evaluation and use by the customer at the end of a sprint. Projects managed in a "command and control" style often have an infrequent release schedule. This can result in a gulf between customer expectations and reality. Scrum requires these predictable, frequent releases to ground customer expectations on demonstrated, working code rather than the false comfort of forecasts and reports. Short of an emergency, stakeholders aren't allowed to approach developers formally or informally with requests to do additional work during a sprint. This gives the development team enough stability to be able to complete a product increment without being distracted by the noise of external disruptions.
-----
Now that last part about not having stakeholders formally talk to developers is something that I try to enforce on my projects also. So, maybe it's not so different after all...to learn more visit:
ITWALES.COM - Agile Project Management with Scrum:

Agile Software Development: New Project Management Paradigm ...

According to article, traditional project management methods must be transformed to enable agile software development and service-oriented architectures. This new paradigm requires an organization that shares knowledge freely and quickly. An organization's readiness to work in the new paradigm of open collaboration is an indicator of success with agile software development methods. ...

... "Contrast that view with ASD, where scope creep is a given, changes happen often, developers respond quickly to those changes and, consequently, knowledge must be on hand at all times. Add in the service-oriented application method, where applications come together via units of work to be performed by a person, computer or team, and suddenly knowledge must not only be available, it needs to be shared freely and viewed as just one more piece to maneuver on the chess board. " ...

Agile Software Development: New Project Management Paradigm: Via Knowledge@W. P. Carey: Ready or Not, New IT Paradigm Requires Knowledge Sharing -- Part 2 ...

Agile Scrum: Game Software Development ...

In this interview, Clinton Keith, CTO High Moon Studios, discusses Scrum, which is being adopted for game development. ...

... "Agile Methodology is an approach to making products that is different from the typical development approach, which involves writing large documents, implementing features and putting it all together at the end of the development cycle. ... Scrum is just one of the four major Agile methods that are out there. " ...

Agile Scrum: Game Software Development: Via GameDAILY Biz: The news source for video game industry professionals

Via Vivendi Universal Games: VIVENDI UNIVERSAL GAMES ACQUIRES HIGH MOON STUDIOS: "Over the past year, High Moon earned numerous accolades for its development accomplishments. In December, High Moon was named among the Top 50 Technology Innovators of 2005 by IT Week for applying Agile Methodology to its development of next-generation games. The studio's adoption of the innovative R&D method also earned it a 2005 Workplace Excellence Award from the San Diego chapter of the Society for Human Resource Management. High Moon's critically acclaimed first-person shooter Darkwatch has been recognized with several art and animation awards, including five Davey Awards, two Aurora Awards and a Telly. "

Scrum: Microsoft Adopts For Project Speed ...

In keeping with our scrum theme, this method focuses on delivering value early in the product lifecycle. Simon Avery reports on Scrum software development method employed by Microsoft to accelerate new product cycle time to market. ...

... "To get its classified system to market as fast as possible, Microsoft is relying on what it calls the scrum method of software development, which involves a very small team of engineers. For the on-line classified product, code named Fremont, there are just six developers. " ...

Via The Globe and Mail: Executive Decision: Classifieds force sluggish Microsoft to scrum

Additional resources on Microsoft and scrum ...

Via Microsoft: Download details: Project 2003 Tool: Scrum Solution Starter: "Scrum is an Agile project management practice that employs short iterations and continuous improvement. The Scrum solution starter extends Microsoft Office Project Professional 2003 or Project Standard 2003 and enables project managers to perform basic Scrum work. "

Via Chris Flaat's WebLog : People are not fungible resources: "We are currently using both Scrum and more traditional project management on several efforts going on within our product unit, and I thought I'd share some learnings. Something we're running into is that getting people dedicated to one effort can be hard, depending on the management style of the relevant managers. "

Software Tools and Methods: "This presentation started with a brief context-setting look at why Agile approaches are gaining in popularity. It then discussed the fundamental principles that are common to most Agile methods, and used the Scrum approach to give a more detailed view by example on how Agile projects work. "

Scrum - Agile Project Management

What is Scrum? "Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices."

The book, Agile Project Management with Scrum by Ken Schwaber says that it has been used successfully on thousands of projects over the past 10 years.

Have YOU used it? Have you had success with it? Has it failed you? Let us know!

Find out more (like how to become a ScrumMaster) at:
Control Chaos

Project Management Success Stories; Learning from the Past

There's nothing like learning from others who have "been there and done that" to expedite our attempts to try something new. It's sort of like asking for directions versus driving around for hours fruitlessly.

For example, for those considering implementing Critical Chain Project Management (CCPM), here's a list of CCPM Success Stories from the Goldratt Institute.

And if it's Agile Project Management you're considering, here's a great Agile Project Management success story from Computerworld, which shows how Sabre Holdings Corp. spent $125 million on a failed project to overhaul their reservation system in the late 80's, and then tried another attempt more recently, this time with a more agile approach, and had tremendous success.

All too often, organizations attempt to undertake huge initiatives without learning from others' successes, and more importantly, their failures.

And the past doesn't have to only include the recent past. I've been writing about project management "lessons from history" for years now, and some of the successes and failures of such notables as Caesar, Augustus, Napoleon, and many others bring lessons that are directly applicable today. For instance, Napoleon was using Earned Value before it was "invented" 200 years later.

I am absolutely convinced that the search for the "next big thing" will undoubtedly bear its best fruit through closer examination of the past.

Project Management Biggest Challenge for 2006

According to a Computerworld survey, 33% of respondents rated project management as their #1 management challenge of 2006, even ahead of budget constraints and regulatory compliance. Specifically, the biggest challenges, according to Computerworld are:

1) Managing Global Teams (understanding cultural differences, language and calendar differences, offshore resources, etc.)
2) Moving Parts (i.e. managing complex projects with multiple threads, multiple sponsors, outsourced resources, and multiple phases)
3) Iterative Development (adjusting to more agile approaches, which have proven to be more effective)
4) Vendor Partners (managing outsourced resources, integrating managed service providers, etc.)
5) Project Portfolio Management (i.e. categorizing projects and focusing on the most important work)

It looks to be a busy year for project management consultants. For more info, read on ...

What's Next: Project Management - Computerworld

Agile Project Management Ecosystem: New Partners ...

Rally works to develop an agile project management ecosystem by adding new partners. ...

... "Rally actively partners with industry-leading companies to help customers acquire the development and project management skills needed to succeed with Agile, one of the world's fastest growing technology trends. Rally's Development and Coaching partners provide a comprehensive network of expert resources that offer a wide range of business, process and technology services related to planning, building and delivering software in small batches that provide immediate business value. " ...

Agile Project Management Ecosystem: New Partners: Via Rally Software: Rally Software Development Adds New Agile Partners ...

Based in Boulder, Colo., Rally Software Development offers the only on-demand, software development management solution that helps software organizations scale Agile development practices across the enterprise and around the globe. The company’s customers include leading software vendors, Internet companies and corporate development teams who are committed to responding faster to new opportunities and changing customer demands. With Rally, larger or distributed teams are able to define, develop and deliver high-value software in rapid iterations. Rally’s world-renown coaches and expert partners complement its on-demand tooling with training, mentoring and consulting services for creating the Agile organization.

Agile vs Big-Bang Project Delivery; Argument Solved

For years now, proponents of realistic IT approaches have been touting the importance of agile or spiral development. And aficionados of traditional "plan everything up front" approaches have been counteracting this by stating the need to agree to a fixed scope, and stay on time and on budget.

Several weeks ago I mentioned an excellent book that addresses this subject; Software Projects: Evolutionary vs. Big-Bang Delivery, by Felix Redmill. I finally finished reading it, and it points out how to resolve the differences, with a reasonable and sensible approach.

Again, the book is expensive (well over a hundred dollars), but can be found used for around fifty dollars on Amazon.com.

Below, I've paraphrased and summarized the key points:

• Be sure to understand and state the business objectives up front. This is too high level for an adequate estimate, but it's a start.
• Then conduct a feasibility study, analyzing as much detail as possible before authorizing the project. Most organizations skip this step, with bad effect. Aim for an aggressive but realistic target.
• Beware of random constraints assigned by senior management, with no strategic cause. Most projects fail because they attempt to hold to unrealistic or arbitrary constraints. If necessary, document the risks of adhering to the arbitrary deadline and review with them. Negotiation tradoffs in scope, time, or cost as needed - or break the project into multiple phases.
• It's still too soon for a definitive estimate, but the results of the feasibility study should be submitted as an "order of magnitude" estimate, along with risks and a plan for mitigating them. This becomes the business case for the project.
• Make sure senior management understands that change is inevitable as the project progresses. But this change should be still be governed and weighed against the business objectives. Reassessment gates can be used to reset expectations of when the project ends.
• Not all change should require governance. Project managers should have the leeway to use their own judgment to change tactics accordingly as long as it's within the business objectives. They should not just "follow procedures."
• It should not be expected that all work will be done within the confines of the original document. For instance (and this is my example, not from the book), if implementing a purchased software project, a feasibility study would have been done before the software was purchased, configured, and tested. Upon configuration or testing, new discoveries/issues can (and probably will) occur. The only way to truly mitigate this is to do a pilot. Aside from that, expect changes.
• This is a HUGE culture change for most organizations on the part of senior management. Without this level-setting, management will expect all work to be held to the original estimate, and judge success against it. This is the key reason why most IT projecst are seen as failures. We must manage stakeholder expectations (and that includes senior management).
• Project progress should be weighed regularly against business objectives and not the completion of tasks. These objectives and the project's ability to meet them should be reassessed at each phase gate, with escalation of any variances to management. Again, this is the time to reset when the project ends, if necessary. This is also a huge culture change for senior management in most cases.
• Scope should be revised as needed and documented at each step, so there's a record of the approvals and rationale for changes. Reasons of variations should be captured as lessons for future estimating.
• Agile or evolutionary development is not an excuse to ignore change management. But change must be expected. To hold firm to a detailed schedule up front is not realistic for most IT projects.
• Maintain close contact with users throughout the project to assure success.

This sounds like a sensible approach, but does require level-setting with management. Again, many project failures are a result of not setting the right expectations with management. Otherwise, a project can be a complete success, but management is dissapointed. This destroys morale and unfairly judges the project as a failure.

I recommend the book for those who want to learn more, as the book goes into far more details and offers examples, processes, etc. Here's the Amazon link...

http://www.amazon.com/gp/product/0471933430/102-4494239-8790520?v=glance&n=283155

Project Planning Tip: Facts are More Important Than Theories

When planning your project or solving a problem, always remember that facts are more important than theories. This means that agile approaches, rolling wave planning, prototyping, etc. should be used where appropriate, in order to base decisions on facts. The alternative is to plan all future phases in detail up front, which is tantamount to basing your decisions on pure theory.

Likewise, the project approach itself should be based on a visit to the customer to see how things are currently done, and get a true understanding of what is needed. Often, what's really needed isn't what is stated in the project request.

In A Scandal in Bohemia, Sherlock Holmes (by way of Sir Arthur Conan Doyle) said, "It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

This is sage advice for project managers as well.

Innovation: Agile Project Teams ...

Companies are trying to break out of "commodity hell" through new product innovation. Embracing innovation requires acceptance that most projects fail and that project teams must be agile - quick, light, etc. Every "failure" yields something of value: data, information, experience, learning, prototypes ... which must be leveraged and reinvested to continue the hunt for the next great idea. ...

... "Bezos isn't just stubborn. He makes his constant experimentation economical by keeping project teams small and nimble. That way, even when they fail, they haven't spent much time or money. " ...

Innovation: Agile Project Teams: Via Business Week: Building An Idea Factory

Project Management Myths

Glen Alleman has an interesting post on his Herding Cats blog. He talks about the three erroneous assumptions of traditional project management. He raises some good points that again support an agile, realistic approach to projects.

Above all, he points out the myth that "accurate predictions of project duration and resource demands are possible once the requirements have been determined." On many projects, especially in the IT field, these things are discovered well into the project, which is why an agile, or at least a rollling wave approach makes sense (where phases are planned as their horizon approaches).

It's a shame the PPM acronym is already taken, or I'd use the term "Pragmatic Project Management" to define these more forward-thinking approaches.

I do agree with one person's posted comment though that change requests should at least be tracked and approved, assuming they impact any promised deliverables or target dates. We don't want to throw the baby out with the bathwater.

Herding Cats: Three Erroneous Assumptions of Traditional Project Management

Software Project Approach; Evolutionary VS. Big-Bang Delivery

It's been a debate for some time now. Should software projects follow an evolutionary approach (i.e. rolling wave, time-boxed, agile, etc.) or a traditional waterfall, big-bang approach.

I can say that modern thinking is that the evolutionary approach is best. But it's not without its own problems.

If you're looking for a book that compares each and makes this case soundly, check out Software Projects: Evolutionary vs. Big-Bang Delivery, by Felix Redmill. It not only examines each approach, but offers solutions to the problems inherent in evolutionary delivery.

It's pricey at $130, but used copied are available on Amazon for $52. If you need to make a case or are looking to better understand evolutionary methods, it may be worth it.

Here's the Amazon.com link below...

Amazon.com: Software Projects : Evolutionary VS. Big-Bang Delivery (Wiley Series in Software Engineering Practice): Books: Felix Redmill

Extreme Project Management (XPM): When Under the Gun, It's the Only Way

I must confess I'm a big fan of Extreme Project Management, otherwise known as XPM or Agile Project Management, in the right circumstances.

This is not the antithesis to traditional PMI processes; it merely takes a more realistic approach to project situations where there is great uncertainty (like many IT projects) or a severe time constraint (like many IT projects).

The key to making it work is a heavy focus on stakeholders and constant communication. It is anything but a "wing it" approach, as I've written about on PMThink several times. As opposed to "mechanistic" processes, which is the focus of typical Business Process Modeling (BPM), it relies on human interaction management, which addresses "human-driven" processes.

Here's the Wikipedia entry on Extreme Project Management, for more info. Also, be sure to check out the link to Human Interaction Management for examples of human-driven processes.

Extreme project management - Wikipedia, the free encyclopedia

More PMO Advice: Focus on Principles, Not Rules

Here's another good presentation (PDF format) on how to improve PMO success-- this one states the need for a "Next Generation PMO."

The presentation, from Projectize.com, talks about the need for PMOs to be less rigid; less focused on rules and internal processes; and instead focused on being agile, flexible and innovative in order to satisfy the business need.

Instead of rules, it suggests focusing on principles for success, providing people with a compass to steer them in the right direction, rather than a dense playbook to follow.

Good advice indeed.

http://www.pmiglc.org/pd/docs/0411_din_mtg.pdf

ITIL Heals Information Technology ...

It is believed that a foundation of ITIL will ease the transition to service oriented architectures, SOA, enabling IT organization to be flexible and agile in response to marketplace competition. David Stodder and Sue Bushell explore the ITIL best practice framework that is key to the success of information technology as the industry shifts to a service orientation in architectures and in delivery. ...

ITIL Heals Information Technology: Via Intelligent Enterprise Magazine: IT: Heal Thyself

... "To reduce error and avoid reinventing the wheel, organizations are working with best practices such as those outlined in IT Infrastructure Library (ITIL), Control Objectives for Information and Related Technology (COBIT) and Capability Maturity Model Integration (CMMI). Judging by its momentum, ITIL is the most important framework. " ...

Project Management Process Head Start

Need a head start defining your project management processes; or just want to get some methodology ideas? Check out TenStep.com, which offers a full project management methodology free on their website. It also offers some good comparison charts, comparing their model to PMBOK, PRINCE2, SIx Sigma, and Agile methodologies. Some interesting stuff here.

Home - TenStep Project Management Methodology

Project Management Software: Ivis xProcess Tool

Ivis opens up distribution channel with Programmer's Paradise for xProcess software ...

Project Management Software: xProcess Tool: Via Ivis Technologies: Programmer's Paradise Adds Ivis Technologies' xProcess Software to Its Process and Project Management Offerings ...

... "Programmer's Paradise, Inc. (NASDAQ: PROG - News), a leading independent marketer of software tools for technology professionals, today announced an agreement with Ivis Technologies to market and to distribute their newly updated enterprise process management tool, xProcess. xProcess is a live, service-oriented, server-based environment that brings flexibility, control and visibility to process management enabling agile planning, project execution and process improvement across the enterprise. " ...

Project Management: Spiral Development Definition

Project Management: Spiral Development Definition: Via Federal Financial Institutions Examination Council: Development and Acquisition Glossary: Spiral Development Definition ...

... "Spiral Development: An iterative project management model that focuses on the identification of project and product risks and the selection of project management techniques that best control the identified risks. " ...

Additional spiral project management references:

Spiral Development: The spiral model encompasses features of the phased life cycle as well as the prototype life cycle. However, unlike those life cycles, the spiral model uses risk analysis as one of its elements. ...

System Life Cycle (SLC) is defined as a structured development approach with defined activities, phases, products, and reviews that provide a standard to support the development of systems from identification through implementation, operation, maintenance, and eventual retirement. The systems life cycle process is a basic requirement for systems development. There are a variety of life cycle models, such as: waterfall, spiral, evolutionary, decomposition (or stepwise refinement), and formal transformation. The choice among the models is made based on the specific project. ...

SDLC Process: Discusses the application of software assurance best practices in the context of various SDLC methodologies, including RUP, XP, Agile, Waterfall, and the Spiral Model. ...

Project Management: EVO Evolutionary Method ...

Upcoming seminar on Evo project management evolutionary method ...

Project Management: EVO Evolutionary Method: Via UNICOM Seminars: The Agile Evolutionary Project Management Process ...

... "Evo Project Management Seminar, with Tom Gilb: Evo is the most successful alternative project management method, if you look at practical experience, and is now a mandatory guideline at US DoD. Event Date: Tuesday, November 22, 2005 ...

Evo has major impact on the whole way in which systems engineering is carried out. All systems engineering processes (requirements, design, build, test, and quality control) are suddenly encapsulated into an early and frequent evolutionary result delivery step. If you know what you are doing you will soon produce results for stakeholders. If not, you won't; and must consequently fix your engineering processes and designs. " ...

Project Management: Strategic Tool: Agile Enterprise

Business success is increasingly reliant upon executing change and transformation projects. Fostering a project management competency is one way to position the enterprise for the future. As the pace of change accelerates, the need for flexibility and the speed attained through agility become critical factors for success. The folks at PWC explore program and project management performance in support of the agile enterprise ...

Project Management: Strategic Tool: Agile Enterprise: Via PWC: Boosting Business Performance Through Programme and Project Management

... "The successful organization employs project management as a strategic tool to respond to this changing environment and to outperform those that do not adapt. An organization that excels at project management becomes an agile organization that knows how to deal with and drive change. " ...

PMThink references on change:

• Project Portfolio Management: Organizational Change Perspective PPM


• Project Change Management Culture Key ...


• Transformational Change IT Projects; Transformation or Emulation?


• Telecommuting Trend Forces Changes in Project Management


• Project Management Change Control: Benefits SDLC ...


• Process Change or Process Tool First?


• Starbucks Acquires Ethos Water: Who Says Projects Can't Change the World?


• PMP Exam Certification Changes: New Scoring, Eligibility Criteria, Credentialing

Scrum Project Management

Interesting Scrum project management flash video and insights on agile development ...

Project Management Lifecycle: Microsoft VS Team Foundation Key

Project Management Lifecycle: Microsoft VS Team Foundation Key: Via Developer.com: For Developers, Microsoft Has More in Store than Ever Before

Patrick Gallucci explores Microsoft PDC insights and highlights the role of Visual Studio VS in the software project management lifecycle ...

: "The Visual Studio Team Foundation will be the new working model for development projects. It is the flagship environment for medium-sized to large project teams. It is built around industry standards such as Agile software development and Microsoft Solutions Framework (MSF). " ...

Project Management: FDD TDD TFP ...

Via Ken MacLeod: Feature-driven development, test-driven development, and test-first programming ...

Ken MacLeod explores FDD, agile project management for software development projects and provides good examples ...

... "three practices address either or both project management and coding: Feature-driven development is a project planning and tracking practice. Test-driven development is project tracking practice that uses coded functional tests. Test-first programming is a coding practice. " ...

Agile Project Message: Empirical Metrics

Via Victor Szalvay: Empirical Project Tracking

Spreading the agile project message ...

... "... a talk on using empirical metrics to track software project progress to a collection of approximately 100 Washington state agency IT executives. Our message: stop trying to track project progress by analyzing task level detail (estimated vs. actuals) and instead adopt agile, track velocity, and use empirical measure to predict completion dates. " ...

Project Management Gridlock; With Cost Focus, Throughput and Value Suffer.

For some reason, despite numerous case studies indicating the astonishing results of those who have implemented Critical Chain Project Management (CCPM), organizations are still resisting it. Perhaps they're not ready for speed, and are still stuck in their lumbering bureacracy. Perhaps they don't believe that psychology can play a role in getting people to focus on throughput. Perhaps they're so focused on cost-cutting and cost-monitoring, that they don't realize that improving throughput can give them the cost results they're chasing.

Or perhaps they don't realize that traditional waterfall approaches and bureacratic methodologies could be standing in the way of throughput and thus value (after all, time is money).

An organization either follows a throughput model or a cost model, and never the twain shall meet. The statistics are all in favor of the throughput model. For information on how Critical Chain Project Management can improve throughput and deliver true customer value, see this report from the Cutter Consortium. Be sure to click on the PDF link at the top for best readibility.

Critical Chain Project Management: Coming to a Radar Screen Near You!

Lean Project Management in MSF ...

Lean Project Management in MSF: Via Agile Management: Innovation in MSF v4.0

David Anderson describes key innovative highlights of MSF, such as lean project management, governance ...

... "Lean Project Management: Project management in MSF using Team System takes a Lean approach. The flow of value creation through a lifecycle of progressive functional steps is tracked and managed by monitoring the queue of work at each step. The Work Remaining report uses a cumulative flow chart developed for Lean Manufacturing. " ...

Scrum Project Management ...

Via Control Chaos: What is Scrum?

... "What is Scrum? Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. " ...

Agile Project Management vs. Winging It

Many who are unfamiliar with Agile Project Management confuse it with "winging it." They couldn't be farther from the truth.

While "winging it" is putting complete faith in chance, Agile Project Management relies on frequent prototypes and immediate adjustments. It's the ideal way to control a complex and/or uncertain project, without making the false assumption that everything can be planned up front.

Here's a good article from Agile Attitudes that explains more about the differences between Agile development and "winging it" ...

Agile Project Management; What's It All About?

For those not familiar with agile or extreme project management (the terms are often used interchangeably), Answers.com probably offers the most concise description:

"Extreme project management differs from traditional project management mainly
in its open, elastic and undeterministic approach. The main focus of XPM is on the human side of project management (e.g. managing project stakeholders), rather than on intricate scheduling techniques and heavy formalism."

To learn more, the Agile Project Leadership Network (APLN) offers 8 core principles of Agile Project Management, along with several links and resources.

The Cutter Consortium also offers a wealth of information on Agile Project Management.

Agile Development vs. Big Design Up Front (BDUF); Don't throw the baby out with the bathwater

Darren Hobbs, in his blog, makes a good point that sometimes people design to leave everything to chance just because much is unknown early in a project.

Even though the traditional BDUF method (Big Design Up Front) often isn't effective on IT projects (where much is discovered as the project progresses), that doesn't mean that we don't still need to spend time doing requirements analysis and planning for what is knowable.

Like anything, there's a happy medium. I saw someone else refer to the proper way to handle it as EDUF (Enough Design Up Front).

I still like the Rolling Wave approach for most IT projects, where the whole project is planned and approved at a high level, but each phase is planned in detail (and re-baselined as appropriate) as the horizon approaches. It's a realistic and flexible approach that's proven successful. Of course, sometimes BDUF is quite appropriate. We just need to use the right approach for the job at hand.

Here's a link to Darren's blog...

Darren Hobbs: Analysis is not BDUF

Agile Project Management Software APM: Distributed Visibility ...

Via Rally Software Development: RALLY continues to drive agile development market with launch of RALLY release 5 ...

Rally offers project management tools (APM) that support agile software development practices, enabling real-time visibility across distributed teams ...

... "Scale Agile Project Management (APM) to large, complex projects - New Program Roadmaps and feature complete reports allow customers to effectively plan and manage large-scale Agile development projects involving hundreds of team members distributed across multiple, concurrent projects. " ...

Based in Boulder, Colo., Rally Software Development is the leader in on-demand software lifecycle management solutions for scaling Agile development practices across the enterprise and around the globe. The company’s customers include leading software vendors, Internet companies and corporate development teams that are committed to improving their responsiveness to new opportunities and fast-changing customer demands. Rally marries Agile project management with tracking of requirements, tests and defects so larger or distributed teams gain the visibility and collaboration needed to define, develop and deliver high-value software in rapid iterations. Rally’s world-renown coaches and expert partners complement its tooling with training and consulting services for creating the Agile organization.

Why IT Project Can't Always Be Run Like Engineering Projects

Another gem from CIO Magazine. For many IT projects (and certainly there are exceptions), much is unknown until the project progresses. This calls for a fresh (and more flexible) approach, using agile methods and iterative prototypes. For these projects, traditional project management methods don't quite cut it.

See Rob Austin's editorial from CIO Magazine for more...

No Crystal Ball For I.T. - Editorial - CIO