Accounts of bad projects abound, but what goes wrong and what are some of the biggest challenges in project management?
Before delving into the topic, it is helpful to consider that in order to solve a business problem, a project should be the solution of last resort. Why? Because a project is risky, the outcome is not guaranteed, and timing and costs are unpredictable. An off-the shelf solution by comparison is associated with little or no risk and the costs are known up front.
Why embark on a project? Because there is no turn-key solution available. This implies that the specific problem has not been solved before, or if it has, the solution is not for sale. This means that we have to apply time, money and people to construct a unique solution.
Project management is supposed to coordinate these activities and resources and if successful, reduce risk, add reliability and guarantee a satisfactory outcome. The challenges of project management are as diverse as the problem to be solved, the industry, customer and composition of the project team.
Challenges in the software industry
One of the major challenges in the software industry from my experience, seems to be reliability: Software implementations have a reputation for always taking longer, costing more, and not producing the desired results. Therefore in this blog, I’d like to focus on estimation.
Producing an accurate estimate for a software solution up front is absolutely essential. This is the basis for adequately staffing the project, setting a time frame and managing customer expectations. Accurate estimating is crucial irrespective of whether the project is a three year global SAP roll-out, a six week SAP Best Practice Rollout or a Winshuttle POC project.
When I need to estimate a project, I find it useful to start with a work break-down structure (WBS). This is essentially a division of a larger problem that needs to be broken into smaller and smaller parts, where each individual task represents an activity which can be estimated with reasonable accuracy.
It’s also important to conduct a detailed analysis of the requirements. For a small project, like a Winshuttle Workflow POC, this means analyzing the workflow and its participants, the design and special features on each of the views, and web services and any other special requirements. Be sure to include testing steps. An example of a WBS for a Winshuttle POC might look like as follows:
The challenge of assumption
One of the challenges for estimating small projects in relatively new software development platforms like Winshuttle Composer is that no prior experience exists for some requirements. Therefore, assumptions must be made. In the example above, I assume that a web service is available for the tax number check. It’s important to document and list any assumptions made during the requirements analysis, so documented assumptions are visible and can be confirmed or disputed. In the latter case, the estimate should be refined.
More complex projects like large SAP implementations require an entire team of experts to conduct a detailed requirements analysis. Often the solution architect will provide the overall estimate. The challenge here is to obtain consistent and comprehensive output from the team, (notoriously difficult with a team of experts) which will allow the solution architect to construct an overall WBS with a fairly reliable estimate.
I have approached similar projects by working with an SAP Best Practice Framework, and this gives each expert a finite set of processes to analyze. A list of gaps (specialized customizing, program requirements, and interfaces) should be an outcome for each process analysis, with an estimate of how much the process deviates from best practice. Clear definitions and good templates up front work well.
With consistent team input, it is possible to construct a very detailed WBS that forms the basis of the project schedule. A project schedule reflects the assigned resources, in addition to the WBS and the resulting dependency and time constraints. This is an essential tool to manage a project effectively.
Sadly, many project managers I have encountered do not use a project schedule; they use PowerPoint instead. This effectively renders the project manager blind to project issues, resulting in scope creep, project delays, excessive hours (& nights) of work, missed deadlines and an irate customer.
Providing an accurate estimate, developing a workable project schedule and tracking progress provides transparency, and increases the credibility of the service provider. Most importantly, reliably meeting expectations, will ensure satisfied and happy customers.
Questions or comments about this article?
Tweet @Winshuttle to continue the conversation!