Dependency tracking- Why it’s important
Similarly to tracking resources, keeping track of dependencies between tasks helps avoid delays. Thanks to that, you know which prior task or tasks need to be completed before the next task can be finished.
Tools
In a multi-man-year projects you can use a GANTT chart to track dependencies.What’s more, you can also track a critical path through all the tasks. For smaller projects, keeping a list of key dependencies is enough.
source: https://en.wikipedia.org/wiki/Gantt_chart
Gantt chart
Linking tasks gives a good view of what’s next. For dependent tasks, if the first task is postponed you don’t need to go to every task and change the dates. All the dependent tasks go along with the first task.
An example of a dependency is:
development cannot start until
database design is complete
database server ready
and
user interface prototypes are signed off on by client.
(you can’t start coding until you have a database!)
How to know which tasks to focus most on
The Critical path is a set of tasks that are critical (in the previous case – the database server is on the critical path). If they are delayed, the whole project will be delayed.
Some other tasks like writing the user training manual can be done anytime.
You only have such amount of time and effort, you want to focus especially on those tasks that can hold up the whole project.
Versioning- why it’s important
I recommend releasing multiple versions of your application. You don’t want to have the ongoing “death march” project, where you never know if you're done. Instead, it’s much better to split up projects into smaller chunks. Then release one piece at a time and make sure they work ok. After that, you can move on to the next version with extra features from the next group of enhancements.
Waterfall vs Agile
SOURCE: Http://www.agilenutshell.com/how_is_it_different
Smaller projects – Waterfall approach
The biggest downside of waterfall approach is the cost of change. Waterfall method is a good fit for smaller projects with clear requirements, when there is a low probability of change to be required.
- Your customers understand costs, size and timeline for their projects;
- Every phase contains specific deliverables.
More complex projects – Agile approach
Still, in most cases, ColdFusion projects are more complex and will require multiple iterations, based on testing and users feedback (to make sure that it’s something that users want once it’s deployed). In such case, in case of changes, waterfall method will be more costly and risky.
Risks of Waterfall approach:
- technical risk because you only test your design or architecture until late stages of the project.
- product risk because don't even know if you are going in the right direction until it's too late to make any changes.
Agile allows for continuous improvement and shorter planning cycles. Continual ‘show and tell' sessions allow for product agreement. You can involve key project stakeholders – product will be built based on priority and accuracy.
SOURCE: http://www.agilenutshell.com/how_is_it_different
Less risk with Agile approach:
- Testing from the beginning constantly improves quality
- You have more control and visibility because you are half-way through the project after building half of the features.
- Product risk is smaller because of early feedback
- Key stakeholders can suggest changes which can be implemented relatively cheaply.
Agile method comes with some disadvantages:
- Planning (and setting a specific deadline) can be tricky.
- Team must be comfortable and skilled inthe chosen Agile framework
- Difficult to operate in big teams
Task lists- why it’s important
Task list is one of the keys to good planning a project. The more defined your project scope is, the easier it is to follow it and fit within deadline and budget.
What makes a good tasks list?
- It’s numbered
- Clear task names and descriptions
- No more than 5 days of effort in any task.
For “black-hole tasks” which involve weeks of effort or unclear requirements, there’s a high risk of budget overruns. Because it’s possible that those tasks mean some confusion or extra complexity, they're just going to take much longer than you thought they would.
- Comprehensive – all tasks are included
Some tasks often neglected are:
- data migration,
- integration testing,
- load testing.
Tasks estimates
If you are new to making estimates, I suggest making your best guess for the time required for each task. If possible, you should also have another developer review your estimates. Making accurate estimates for tasks is much easier when tasks are split into smaller pieces.
Milestones
To keep the project on schedule, I recommend you break up big deadline into sub-deadlines. These are called milestones. It also improves the morale of the team since they see small wins through out the project.
For example, you might have milestones for:
- Prototypes completion
- Prototype review and sign off by client completion
- Database design completion
- Development completion
- Provision of test data by users
- Software and servers purchase
- Staging and live servers configuration
- Internal testing completion
- Data migration completion
- Acceptance testing by users on staging server completion
- Acceptance testing by users on live server completion
Tracking percentage is misleading
Track the planned date for each and the actual completion date.
Note that milestones concern a task being 100% complete –it’s not useful to have a 50% or 90% completion milestone because that’s a subjective measure. A milestone is a binary (yes-no) state –it’s either complete or not. Don’t track a percentage completion. Often when a task is “90% complete” it means you’re only half way through!
“In computer programming, there is a rule of thumb called the ninety-ninety rule. This explains the effect of standard deviations on software projects: the first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
This is true of any project I’ve encountered.
When you’ve got 90% of a book written, you’re probably about halfway through.
When you’ve got 90% of a product design nailed down, you’re about halfway to a final design.” – from the rticle by Taylor Pearson https://taylorpearson.me/fast/
Track time for better estimates
Track how many days early or late each milestone is. This will let you estimate the total slip on the final deadline.
I account for slips caused by the client and by the software development team differently.
- A client-caused slip extends the official deadline and I notify the client of the new deadline that we are doing our best to meet.
- A team-slip does not extend the deadline (but I still notify the client of the estimate delivery date change).
Improving your estimates
When the project is complete.compare your original estimates to how long each task lasted. (You are tracking time you spend on each task, right?). Then you can see where your estimates were accurate and what needs to be improved next time. If you don’t track, you can’t tell if there is a systematic under- or overestimation on all the tasks.
Better project visibility
If you don’t know what tasks are complete, you don’t know how much of the project is done. You don’t know whether you’re behind or ahead, you don’t know who is working on each task, they don’t what tasks they’re working on. I’ve seen projects where lack of tracking caused some tasks to be done twice by two different people or not done by anyone at all.
Tools
Most popular are Windows based Microsoft Project or web based Basecamp.
There are hundreds of project management tools for teams, with different functionalities like: time tracking, risk analysis, issue tracking, GANTT diagrams.
Here’s an overview of the most popular ones: [link: http://www.businessnewsdaily.com/8237-choosing-project-management-software.html]
Risk reduction
Only five percent of survey respondents said that they do some kind of risk analysis. Risk analysis is looking at what could go wrong and then coming up with a plan-B, or mitigations that deal with that risk. This practice prevents coming up of unexpected issues that delay the project.
Examples:
- the DBA isn't available at a key time
- the users didn't understand that they were supposed to give all their feedback upfront when you've gone through the formal signoff but they didn't give all their real feedback till you actually delivered the app.
How to start?
Coming up with that is, to some extent, experience with what things can go wrong.
- You can have a checklist of common things
- Brainstorm on what extra risks can come up.
- Look at the dependencies (are there any you’re not sure that would succeed?) ,
- Look at tasks list (any tasks that seem less risky or depend on people from outside of the organization?),
- Take a look at the technology (maybe it depends on a new technology that you haven’t tested before)
For each of those you think what the workarounds are or how we can find out if this risk can really happen.
Example: if you’re using a new version of software or a new technology, a mitigation would be writing some trial code to test it out. This simulates the amount of data that you have to see if it works.
Regularly (each month) review the risk list:
- how many of these risks that we need to deal with have come up
- are there any risks that are more likely
- are there any new risks that need to be addressed?
SUMMARY
We’ve covered the most important methods to avoid project delays and going over budget.
I’ve seen projects where everyone thought ‘it’s going fine’, until the project was deployed and turned out to be not working…Those methods give the project manager more control and visibility on what’s going on so they can make adjustments during the project.
