Don’t overwrite project files

The Better Projects blog, which is run by Craig Brown, has touched on the topic of configuration management recently.  The focus of the blog is on software development projects and it often takes a business analysis angle.  However, any project requires good configuration management processes – and project managers as well as business analysts can use config management techniques to ensure that project files and products are kept in order.

Configuration management is the business of creating, maintaining and controlling the change of configuration during the project lifecycle.  A Config Management Strategy sets out how products will be controlled and protected, and who can make changes to them.  Projects will also have a config management system, which is an approach that is used to manage config data.  You might use the config management system of your customer or supplier rather than reinvent one yourself, although your PMO probably has an approach to use in the absence of anything else.
Read more »

Ten Characteristics of Successful Project Teams – Part 1

Have you ever been a member of a high-performing, smoothly running team? If you have been, it’s an experience that you are not likely to forget. On this type of team there is usually a strong trust bond, people work cooperatively together to reach the common project goals, and often the project is even more successful than the project manager and customer could have imagined. These types of teams generally have some key characteristics in common that help make them the effective, high-performing teams that they are.  In this series, we’ll examine ten key characteristics of these types of teams.

These ten main characteristics of successful project teams are:

• Clearly defined goals
• Clearly defined roles
• Open and clear communication
• Effective decision making
• Balanced participation
• Valued diversity
• Managed conflict
• Positive atmosphere
• Cooperative relationships
• Participative leadership

For Part 1 of this series, we’ll examine the first two in more detail: clearly defined goals and clearly defined roles.

Read more »

Maximizing the Project Budget: Knowing When to Downsize

We often walk a very thin line on our projects between budget success and budget failure.  It really doesn’t matter if you’re working with a $50,000 project budget or a $5 million project budget.  It’s all planned for and it can get eaten up rather quickly if it’s not being forecasted and tracked carefully by the project manager and delivery team.

Resource utilization on the project obviously plays a key role in the successful management of the project budget.  Carefully administering the project schedule and task assignments to strategically know when to onboard the right resource is critical to the project’s financial success.  You can’t afford to bring your lead developer on at, say, a $130/hour bill rate to the customer if you’re only in the project kickoff phase.  Using a nice project planner such as Seavus’ Project Planner for resource planning activities can go along way in planning out all of your resource usage.

There’s no reason to fill your entire team out at the onset of the project when the early work of customer requirements review may only need the involvement of the project manager and business analyst.  The danger of course, is that the right resource may not be available when you actually do need them due to unforeseen circumstances on one of the company’s other project engagements.  However, carefully project planning and forecasting of resources and the budget should help you get the personnel you need when you need them.

Read more »

Considering a Phased Project Delivery

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

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.

Read more »