A project flows like a river. Similarly the flow of traffic. In order to move ahead, you need to be able to gauge the speed of the traffic with the some moving faster and others moving slower then you. When changing lanes you need to view the object  behind you through your rear and side mirrors as well as where the road is heading. With a project, your need to know what tasks are in front of you, in the schedule which may or may not be dependent on the task, and and if there are any dependant activities that are lined up before inserting a task into the schedule. If you do not understand the flow of the project then you may insert a task too early hence it will divert your resources which can be better utilized at that point of time or too late which may mean that you may not be able to complete on time and worse still hold up other tasks that may be dependant on this particular task. Just as when you are driving in traffic, mis-timing changing lanes may cause tr...

My post yesterday discussed the learnings that we could obtain from our drive to work. Here are a few more observations that are along the same topic. Each project is like a journey. When you start your journey, you will have a few decision points in your journey which will determine how fast you will be able to reach your destination. Similarly there are several decision points when the project starts. Existing Resources Some of the decision points have been made earlier for example the car you are driving and the location of your residence so you will need to work within these as your starting point. In a project persepective, your resources may also already be pre-determined by decisions made earlier depending on the type of project eg. the number of team members and their skill sets, hardware, software etc. Timing to start The first decision point will be the time to start your journey. This will be made based on the information that you have and your previous...

 Driving to work this morning, I hit the start of the highway and ran smack into a huge traffic jam. Four lanes were chock a block. Really unusual to be so bad. The right hand lane was moving a little bit faster as there was a right turning junction ahead so I maneuvered toward the right most lane and headed towards the junction. While trying to see if there was an opportunity to cut back into the lane, I noted that the queue ahead also was not moving very much. Must be an accident or something causing an obstruction ahead. Bearing in mind that the route ahead would also needed me to negotiate another set of traffic lights which would have a long queue normally, I decided to try route B, which was to make the turn off and cut across to the other main road to take the route around the back of the area where I worked. Surprisingly, the route which was normally busy was quite smooth and I got to work quite quickly. So what can we take away from this experience in terms of project...

What is ORT ? ORT is Operation Release Testing. This is part of the software release development cycle which helps to ensure the quality of the of the software being release. This type of testing is more relevant to new applications being released as this allows users to conduct testing in the live production environment. Typically on the release day, some testing will be done in the production environment to determine if the changes or new application is working as was tested in the user acceptance testing (UAT) in the development environment. ORT will normally be allocated a longer period where the business users will test in the production environment. A few reasons why a longer period of testing in the production environment is a good practice : development environments can replicate closely the production environment but never exactly due to budget contraints network connectivity differrences differrences in traffic volumes differrent traffic timings availability of ...

Aligning business partners expectations, marketing or public relations (PR)...essentially the same task which can make a good project great and even a bad project into a good project. Essentially expectations can vary between individuals and thus this is the most tricky aspect of any project. Each stake holder has to be managed individually but with a collective goal in mind. What may seem to be normal to one person may be an extra functionality to another. Expectations will determine the degree of acceptance of the project as the whole and degree of tolerance to any open defects as well as how much flexibility there will be to the time required to resolve.  

Proper Ramp Up Planning Most projects then to run to a specific deadline where the end point is the project deployment date and stabilization. Stabilization is generally a 2 week period on the whole but can vary from project to project. Naturally this can also vary from industry to industry but the main concepts are ideally the same. In IT projects the stabilization period allows the project team to ensure any defects or errors that may have slip passed the initial IT and business user acceptance testing (UAT), are addressed. In the construction industry they would also have a similar period for home owners etc to lodge defect reports where the builders or construction company will be liable to fix. After this period, the support for the final project is handed over to the ongoing support team who would be a separate organization. This period should be set dependent on the type of project and the issues that arise. Although a there may be a standard guide like 2 weeks, this shoul...