At Mobnia we pride ourselves in building digital products that help you succeed. But how do you build a software product that is reliable and robust? This is the third in a series of posts that address this question.
A project always has to be managed. Management helps ensure goals are set, tracked and met. Team members need to be kept focused and decisions need to be taken. Here are some of the key responsibilities that must be handled:
There needs to be a sort of executive champion or sponsor that can ensure a project gets the budget, personnel, hardware, software and other resources it needs to be successful. This allows for work to be done in optimal conditions. Executive support is also critical for allowing the project to continue when faced with unexpected setbacks.
The executive champion helps steer the project through the complex world of corporate politics and sees it through from start to finish. They also need to strike the balance between being involved with the project and not being an obstacle to project completion (by micro-managing and interfering).
A project manager monitors the status of the project and ensures it's heading in the right direction. They are the main interface between customers and the rest of the project team.
In some situations, there may be a mix of project managers from managerial and development backgrounds respectively to give all areas of the project proper attention. To be specific, there could be one with little or no experience in development, but equipped with training in project management. Such a manager would handle scheduling and make sure tasks come in when due or are have their deadlines pushed back to accommodate delays.
The other manager can then be more development-oriented (perhaps promoted from the development team). This manager would work more directly with the developers, making sure everyone everyone is on the same page and that work is progressing smoothly.
This is basically a graph with nodes and links to show precedence relationships among tasks in a project. The tasks to be performed are listed, along with expected duration. Each task's direct dependencies are noted as well. The tasks are then arranged in order of precedence. The start task comes first, those that depend on the start task next, those that depend on the prior task(s) following, and so on until all tasks have been accounted for.
Critical Path Methods
PERT charts are often used with the critical path method. IT lets you find critical paths through the network formed by the PERT charts. The critical path is a longest possible path through said network.
To find the critical path, start from the start task, labeling it with the total time 0 (it takes no time to start). From there, move right to subsequent tasks, one column at a time, setting the total time equal to that task's time plus the largest total time for its predecessor tasks. Highlight each selected predecessor task (the one with the largest total time). When you've finished, you can follow the highlighted tasks back to the beginning to find the critical path.
You can find out more about the PERT technique and critical paths here.
This is a bar chart that shows the schedule for a collection of tasks. Horizontal bars are used to represent task activities. Bar length indicates task duration. The bars are placed horizontally in a calendar to show their start and stop times. Arrows show the relationships between tasks and their predecessors like in PERT charts.
You can find out more about Gantt charts here.
All the above methods depend on you knowing how long a task will take. This is especially difficult as you can't be sure how long something will take until you've actually done it. Once you've done it however, it takes much less time the next time. Here a few things you can do to minimize your risk when stepping into an unknown situation.
One advisable thing to do is to bring in someone who has done something similar to what you need to do. On a large project, it may be worthwhile to bring in experienced hands to handle tricky tasks. Using experienced team members is the best way to make time estimates reasonable.
Break Unknown Tasks into Simpler Pieces
Sometimes, breaking a complicated task into simple pieces that are easier to understand. You may not know exactly how much time you'll need for each subtask, but you can make better guesses than for the more tricky task as a whole.
Look for Similarities
Tasks you don't understand may be somewhat similar to tasks you've performed before. This sometimes goes well with working with experienced hands. You may, for example, never have designed an object-oriented database before. However, since you have experience working with relational databases, you have an idea of how much time and effort is required.
Expect the Unexpected
Not every problem can be predicted but there are some delays that can be reasonably expected. One way to handle this is to add specific tasks to the project to represent lost time. Eg: there can be tasks to represent vacation time or sick time.
Lost time could also come up as your team being delayed in starting work on a project due to some scheduling problem. These can be avoided by careful planning. Look at factors that could delay you (such as approvals) and try to get them out of the way before it's too late.
Sometimes, even when you utilize all the above methods, some things can take much longer than you expect. It's important to keep track of tasks as they progress and take action if one of them is derailing. A team member could be overly optimistic with their time estimates without truly understanding the complexity of the task at hand. As they go deeper, they realize the actual depth of their problem and constantly need to re-calibrate their estimates.
It's important to pay extra attention to these tasks to ensure the task isn't in more trouble than you think. You should neither ignore the problem nor throw more bodies at it (you'd spend even more time on-boarding the new guys and end up delaying the project much more).
This is a more proactive way of handling problems. Here, you identify possible risks, determine their potential impacts and study possible work-arounds ahead of time.
For each task you should determine:
- your understanding of how to perform the task
- the severity or importance of the task, can the users live without the feature?
- what other tasks does this task affect? will it make them fail or render the redundant?
- are there any work-arounds? if so, for each one, consider:
- the difficulty of implementation
- the impact on the usability of the application
- its advantages
- its disadvantages
You can also use your analysis to find out how these problems will affect your project schedule.