Considering a Phased Project Delivery
Posted by Brad Egeland
As we’re delivering on a project for a customer, there may be numerous reasons why the project would be best moved to a phased project delivery situation. The most common is the result of numerous requirements changes or change requests initiated by the customer while initial functionality is still badly needed by a specific date. In a situation such as this, where the project cannot deliver the complete project or product by the deadline, there is still the possibility that it might deliver some useful part of it by the original promised date or close to it.
Technical projects composed of several subsystems, for example, often implement one subsystem at a time. Tenants can move into some floors in a new office building while there is active construction on other floors, and sections of a new freeway are opened as they are completed rather than waiting for the entire freeway to be complete.
Phased delivery has several benefits:
- Something useful is delivered as soon as possible – and in the case of many changes affecting the project, some critical base functionality may still be deliverable by the original agreed upon date.
- Often, as in the case of information systems, phased delivery is actually preferred because the changes introduced by the new system happen a little at a time. This longer time frame can reduce the negative impacts to ongoing business operations.
- Feedback on the delivered product is used to improve the products still in development.
- By delivering over a longer period, the size of the project team can be reduced; a smaller team can lead to lower communication and coordination costs. In addition, because the people are working for a longer time on the project, project-specific expertise grows. These factors should lead to increased productivity in subsequent project phases and to an overall lower cost for the project.
- Phased delivery allows for phased payment. By spreading the cost of the project over a longer time, a larger budget might be more feasible for the customer.
Modularized products, whose components can operate independently, can be delivered in phases. To determine how to phase a project or product delivery, you need to look for the core functionality—the part of the project that the other pieces rely on—and implement that first. The same criteria may be used in identifying the second and third most important components. When multiple components are equally good candidates, they can be prioritized according to business requirements.
Trade-off: Phased implementation increases functionality at the expense of schedule. If the approach requires old methods to run concurrently with new methods, it could also temporarily lead to higher operating costs.
Impact on risk: When components of a solution are delivered over time, the connections, or interfaces, become high risk. For technical solutions, that could mean corrupted data.
Information for this article was derived in part from Eric Verzuh’s book “The Portable MBA in Project Management.”
Why is it So Hard to Plan Well Up Front? – Part 2
Posted by Brad Egeland
In Part 1 we looked at the problem with up front planning and requirements definition and the first of three key American cultural tendencies that can contribute to this problem … impatience with time.
In this Part 2, we’ll look at two more cultural issues – the acceptance of mistakes and the urge to improvise.
Acceptance of Mistakes
America has often been called the land of comeback opportunities. Everyone gets a second, third, fourth, fifth chance and so on chance. In the US, we tend to forget the trials and tribulations of the process and focus only on the end result, saying “Because it worked out okay, there’s nothing to learn.” In fact, we admire comebacks more than people who never failed in the first place. We honor them. We are more loyal to a supplier who quickly fixes a mistake he makes than we are to a supplier who never makes a mistake.
Most people in project and product development assume that mistakes are inevitable. Some mistakes are. However, we often confuse preventable mistakes with inevitable ones. Poor preparation and inadequate understanding of customer requirements result in what I’m referring to as preventable mistakes. There’s really no honor in scrambling at the last minute and running over budget to get out a solution to a customer when it could have been prevented up front with better planning.
Project management and the recession
Posted by Elizabeth
Did you complete the Arras People 2010 Project Management Benchmark survey? If so, your data has contributed to forming a picture of how the recession has affected the UK’s project and programme community over the last 18 months.
It’s the fifth annual survey that Arras have run, and that means they can set the results in a historical context, so we can see the evolving trends. The headlines this year are:
- Programme and Project managers in the private sector have been hit harder than those in the public sector.
- Contractors were the hardest hit group: 42% saw their pay fall compared to only 14% of public sector full-timers.
- However, public sector workers are more nervous about the next phase of the economic cycle and the impact of the forthcoming general election.
Project and programme managers were also asked about their confidence for the coming year. What did they predict for 2010? Read more »
Why is it So Hard to Plan Well Up Front? – Part 1
Posted by Brad Egeland
Why is it that time and time again projects end up with bad requirements? Why do the same project experiences and nightmares seem to happen over and over again?
Imagine this scenario – and it may hit home with you so it might not take too much imagination. You are an intelligent and confident leader. Let’s say you’re in charge of the project and you have a leadership role in seeing that requirements get documented well. You’ve been educated in the ways of project management and understand the importance of good requirements definition. You started your last project strictly adhering to a textbook method of project planning and requirements definition, only to find that the ideas weren’t catching on with your team.
Before you could figure out why it wasn’t working with the team, your supervisor requests a progress update (since this is a very visible project). It seems like a career-killer to tell him that you’re still trying to figure out what to do, so realize that you must get something going and you decide you’re too busy to implement a new process designed to help you do things the right way.
More on Green Business and Project Management
Posted by Brad Egeland
In the US, the 2010 Super Bowl XLIV broke all records for viewership with 106.5 million people tuning in. That’s even more than the 27-year-old record held by the tear-jerking M*A*S*H finale that drew 105.97 million viewers.
As for the Super Bowl ads – well, I would have to say they were sub-par this year. But there was no shortage of car-related ads and my favorite (but remember I’m partial) was Audi’s ad featuring a re-recording of Cheap Trick’s “Dream Police” as the “Green Police.” The ad was for Audi’s green car, the A3 TDI clean diesel automobile. The ad is actually very good and was voted the best auto-related ad of for this year’s Super Bowl. In case you missed it, you can view it here.
It’s obvious that “green” is definitely the new black – or however people are stating it these days. I wrote one article on ‘green’ project management back in May 2009 and I’ve since been asked to write several more and interviewed on the subject for two online articles and a major print publication. Everybody wants to know about going green, apparently.