Build versus buy decisions are crucial for success, but they aren’t simple. Some elements will be developed in house and some will be outsourced. But with such a wide ranging impact, how do you decide on the best approach?
Transitions can be difficult when management and stakeholders change--something that happens on a regular basis in the government. Some basic guidelines can keep the project on track.
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.
Does your project need outside help? You’ll need to consider a few things before making your pitch to the necessary senior leadership and actually bringing in an outside consultant. Here, we cover some key considerations.
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.
Procurement management is one of the knowledge areas in PMBOK, but procurements for large computer systems or multi-year projects can easily take on a life of their own. This article will provide guidelines for issues that are unique to a procurement project. Ensuring that these guidelines are followed (or at least considered) by the appropriate stakeholder will assist the PM in successfully completing the procurement so that the real work can begin.
An effective contingent work team can be procured more easily when you get involved in development of the SOW. Your non-involvement may result in a costly Emergency Executive Intervention.
RFPs are a double-edged sword for many vendors. In the first article, we looked at the challenges with layout and content. In this second installment, we look at the challenges vendors experience in the process from the point they are made aware of the RFP to the submission of the bid.
Have you ever thought about the RFP process from the other perspective--the potential vendor who responds? An RFP response is more than just a proposal to supply products and/or services; in many cases it is an opportunity to showcase a potential vendor to the procuring organization. But when some vendors reply to RFPs, you have to wonder what they thought that they were bidding on. In this article, we flag some of the things vendors should consider.
In the ever-increasing speed trip down the ramp of badly made cost-cutting decisions, many mainstream manufacturers are compromising on the quality of their products. To help address this, we all need to more carefully monitor the quality of our supplier goods.
This two-part article will provide you with some insight into some of the most frustrating aspects that vendors experience when they attempt to decipher the hieroglyphics found in the proposal documents. The first part will focus on the content of the RFP.
Some RFPs are bad…really bad. It makes you wonder how clear the purchasing organization is on what they are trying to achieve. Here, we look at the process that an organization goes through in preparing and issuing an Request For Proposal--and identify some best practices.
Although the 71st anniversary of Operation Dynamo, which took place during the second World War, was celebrated earlier in the summer, we can still continue to celebrate its achievements in the extraordinary results that the use of "crowdsourcing" in projects can deliver.
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?
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.
The use of supplier relationship management (SRM) can be considered symbiotic in nature, since the mutually beneficial aspects of having such a two-way dependent/supportive partnership can make each party’s success tied to the other’s. Can we relate?
The relationship forged with strategic providers can make the difference between success and failure within the organization. Here, the value proposition they represent is often based more on their service and support levels than price. In essence, SPs become de facto stakeholders with the organization--and thus require special consideration in terms of how the relationship is cultivated and managed.
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?
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 do you make a fixed-price contract work? This article investigates the reasons why IT projects tend to overrun the budget--and the mitigating actions that can be applied.
Software is built on a variety of assumptions, and we need to understand what those assumptions are--and work around them in defining how we use the software. With so many options in the marketplace, how do you decide what’s good and what’s not? How do you navigate the promises of software vendors to know what you should be looking for, and how do you decide what will actually work for you?
|