Project Control

Are your teams predictable? Is always delivered what was expected or agreed on? Want to know the impact of scope changes, time pressure, or a lack of domain knowledge when you start a software development project? You often have discussions after the fact, when it’s too late? Or are you having difficulties to communicate the actual progress, or impact of changes?

Be aware of expected challenges from the beginning, when your project starts. Learn to understand what is happening, and act to get back on track or manage new expectations. Become in control, stay in control. Start using objective and comparable metrics that support initiating and planning feasible projects and that support steering processes. No matter if your project is using waterfall processes or Agile, start working towards your real project goals and be transparent during the complete project life cycle.

Know what to expect

You have to understand what your project goals are and which constraints your team needs to work with. The project goals that are committed to at the start of a project must be feasible and realistic. You have to know how big a software development project is, how much functionality should be developed and delivered, what the productivity is in the business domain or IT environment, and what cost and what quality to expect. Experience shows that smaller teams and smaller projects in general increases productivity and reduces costs, but this optimal project structure must match the project goals, and decision makers need to be aware of the options and impact of each of these options. Make sure you understand the project from the beginning. Especially with external suppliers, both parties want to have the right expectations, and the commitments that are made should support your outsourcing partnership relation without too many uncertainties or surprises. Read more about Estimating and Outsourcing and how Nesma provides supporting guidelines and measurement/sizing methods.

Nesma and benchmarking databases such as the International Software Benchmarking Standards Group (ISBSG) help to standardize basic metrics. When the functional size is known then other measures such as productivity, quality, costs and time to market can be expressed in objective and comparable ways.

Objective and transparent progress insights

After the project plans are made or the high level backlog is created the project execution starts with construction phases or development sprints. You or your team has to provide insights into the progress. Don’t get surprised by monitoring or communicating the wrong things. Are you tracking and reporting budget spending? Unfortunately, too often the costs or hours spent are the main measure of progress of a project. These are, however, constraints that need to be managed during the project execution, but are not the actual goals. The real project goals should be expressed in terms of business value of the functionality that is delivered. Stakeholders often prioritize these functionalities based on savings or revenue increases that are the result of using the IT solution. Thus, delivered functionality is what the stakeholders are interested in and what you should be monitoring and reporting. This aligns well with functional size measurement methods that help to create functional breakdowns of software applications and that can be used in progress reporting.

Impact of changes

Changing the scope of a running project by for example adding or changing requirements or adding additional resources to shorten the time to market, can have a big impact in terms of costs or quality and the feasibility of the project. Experience data in benchmarking databases, such as the ISBSG, and estimation tools available in the market can provide insights into the different factors and help to understand the impact of changes you make to a project. Try to keep the project during the execution or during a sprint as stable as possible.