Process > Contract Negotiation

There’s more to vendor management than deliverables and deadlines. Let's look at a few basic concepts that will help PMs avoid some of the biggest pitfalls.

A new agile procurement process--one that can operate in conjunction with and alongside an agile software development methodology--should significantly improve both the procurement of software vendor’s services and and successful delivery of software projects. This article will explore the underlying principles as well as map the reconciliation points required to harmonize agile development and procurement methods.

Agile methods deliver many benefits in terms of their flexibility to cope with changing requirements and priorities. However, this adaptability and reluctance to be tied down on scope can create contract problems when trying to form supplier agreements or outsource work. Part 1 of our two-part series covers the challenges of agile contracting and offers some of the packaged solutions created so far.

How can you adapt Scrum-like tools and techniques within a Waterfall project management environment? What can you do to reduce resistance and reap the benefits Scrum has to offer? In short, how can you get down and Scrummy within a Waterfall world? Here are some ideas you might find useful.

Organizations and teams must come to understand why they need agile before choosing a methodology or tool to implement it. A mandate alone will not work. It is the overarching goals, values and principles of Agile that must ultimately guide teams in the adoption and adaptation of its practices.

For any and all projects you lead, a constant mantra should be “keep the stakeholders involved.” It will help you to get ahead of potential risks and changes to scope as your project moves towards completion, and it will be critical to its ultimate success. When in doubt, overcommunicate.

Some love 'em. Some loathe 'em. But these frameworks and schools of PM thought are here to stay. What benefits and challenges do they present? Read on for both sides of the alternative equation...

Fixed contractual restrictions like timelines, budget and scope can be impractical on the Agile project. Here, Agile thought leaders Rachel Weston and Chris Spagnuolo share some ideas for breaking through the “iron triangle” during the contract phase of an Agile project.

Where evolving procurement requirements come from, and why, is in reality no different than how requirements evolve in any organizational area. The challenge is that they compound themselves, layering restriction upon constraint upon requirement. What can an organization do to improve its procurement efforts? What can be done to make procurement work in support of projects rather than be a barrier, roadblock or black hole?

Agile projects are optimized for different constraints than traditional ones. To truly understand how to design a performance measurement system for agile PM, we need to dig a little deeper into the value system underlying agile methods.

Does the use of agile project management require new contract models in order to be successful? Can agile project management be used with traditional fixed-price contracts? Does agile project management require a new type of contract (and if so, what kinds)? Furthermore, wouldn’t a new type of contract discourage the use of agile PM?

While plans, progress and budgets are all critical elements, we can bring more value to the project by releasing our obsession on these project metrics slightly and focusing more of our attention down the road to items like sponsor satisfaction and team morale.

Contract resources have long thrived in IT, and in tough economic times they have a very big role to play. But how do you maximize your return?

“Cloud” sounds kind of ethereal, doesn’t it? Lofty in some ways, yet soft and comforting like a bed of heaven. With this new system direction, we’re supposed to let our concerns just float away. Not so fast...

The four guiding principles of Agile project management can be compared to the Chinese concept of yin-yang. They are "opposing ... mutually rooted ... mutually transforming ... and mutually waxing and waning." By better understanding how these principles work in harmony, project managers can then translate them from concepts into concrete actions.

Do you have a dual personality? A PM that also has a foot in the business analyst camp has a “leg up” on the competition for jobs--and has more job security.

Small businesses don't have it easy. How can you boost your success and avoid the chronic compromising that could eventually cripple your business? An expert provides some tips.

We've already explored the work necessary to prepare criteria to measure applicants against. In Part 2, we look at the interview and selection process--and consider the steps necessary to maximize your chances of making the right hire.

This article looks at the issues facing project managers when contracting out for project resource, expertise or capability--or to mitigate project risk. And it takes a look at a project that shows how innovation is not just confined to technology but, by using the right kind of contract appropriate to the project's needs, can yield successful results in other ways.

With less emphasis on upfront specs and higher rates of change, how are agile projects contracted? Part 2 of this article outlines building blocks for creating agile contracts.

Are you ready for a revolution? Not so fast. Agile is, quite simply, a qualitatively different way of developing software. And those differentiating qualities are what the Agile Manifesto carefully delineates.

Here we provide some tactical tips to ensure your PPM solution is a successful one that is used frequently and provides data for good decision making.

This will be the first in a series of articles that will look to provide the background of issues involved with managing an agile software development project under a traditionally linear and sequential project procurement process. Software development has been deliberately chosen for the example industry since that’s the domain for which agile is most typically used, but for those using agile in other industry domains, the general issues and proposed solution should work equally well within your industry.