A blog that looks at all aspects of project and program finances from budgets and accounting to getting a pay rise and managing contracts.
Just having bodies in seats is not enough for success; it needs to be the right bodies at the right time. When a project involves a consultant, it is important to evaluate the resource and not take their resume or proposal at face value.
Sometimes it's a knock-down, drag-out brawl between proponents of insourcing and outsourcing. When the final bell rings, who will still be standing?
Done well, contract-based project management can deliver the kind of results that simply wouldn’t be possible using only employee resources; done poorly, it can be a disaster.
Is "consultant" a dirty word? Many consultants get a bad name from the fact that they become indistinguishable from the organizational employees that they work alongside. How do you know that hiring a consultant is a good idea?
Some studies have indicated that the real benefits of offshore outsourcing can be diminished by issues in communication, skill sets and accountability. But if managed properly, offshore IT projects can reap substantial rewards.
Many consulting engagements see frustrated consultants because they are not allowed to do what they feel is needed to maximize the chances of success. Here, we look at how these scenarios can be avoided--something that starts with trust.
What comes to mind when you ponder the possibility of engaging a consultant? Dread or excitement? The high cost or opportunity for growth? Most of us have heard good things and bad things about using consultants, most of which are true.
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.
Some substantive updates to the definition of Scrum artifacts may seem like minor clarifications to terms and definitions, but they have quite profound implications. In this article, we discuss these changes and how they affect the ScrumMaster (or project manager) tasked with delivering a “done” increment.
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.
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.
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.
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?