Please login or join to subscribe to this thread
It depends on the granularity you'd want to track. I can have these tracking tasks:
1) Not Started
2) In Progress
3) In Review
4) In Test
Based on the nature of project you can choose just three to four statuses or pick multiple statuses, depends on the requirements of the project.
Once tasks are defined, I would visually draw a flowchart and connect these tasks and see if the task flow makes sense and then finalize the tasks.
First of all thanks for taking the time to respond. I like all of the statuses that you have posted here.
But as you said, "it depends on the granularity one, wants to track"....and this is interesting...I think the more data we gather the better the analysis and a more accurate predictive outcome one may have based on the tasks statuses.
When you said based on the nature of the project, can you elaborate a bit more?
Can you tell me or can you give me examples of certain projects that you may use certain task statuses vs other projects?
Taking example of software industry where I work,
Support projects have different statuses as compared to Development projects
Say for support projects it would make sense to have statuses such as:
1) Issue Defined
2) In Progress
7) Archive [ once issue is completed and to identify how many tickets came in/resolved in the past ]
For Development projects, these can be:
1) Not Started
2) In Progress
3) In Review
4) In Test
5) Production Ready
6) Deployment Complete
8) Reject/ Rework
9) Deferred until next release
It all depends on granularity you need to track. I would use a status as granular as mentioned here on this chat to track activities so I have fairly accurate status on my gantt chart against each of the sub-tasks;
More granularity would mean that your report would be more accurate and you can estimate better
While sub-statuses might help you gain insights on bottlenecks and opportunities for improving flow, from a customer perspective, they probably only care when an activity (or better yet, deliverable) is done. As such, Not Started, In Progress, Done with 0/100% reporting is the safest bet...
I agree with you in terms of simplicity. But the idea in all of this is to somehow measure the quality of the "human resource" assigned to the task.
With just Not Started, In Progress, Done , one cannot measure the quality of the human resource.
For example how many times the task was rejected? or how many times the task was accepted at once, this data along with a nice algorithm and other data could give us a nice insight of the resource and the task.
I guess I will not like to have a resource that have a lot of his/her tasks not accepted at once or most of the times his/her tasks are rejected. Can we call this resource profiling? :)
I struggle with this approach a bit. Here's why. In my experience status is just that and is temporary, a moment in time that should be reflected on a dashboard. Where are we today? In measuring the human resource, this is a metric that should be measured outside of a status. There are numerous ways to measure quality and rework and within these activities there are specific status that provide information back to stake holders and end users. However consistent metrics reported back to the business reveal pain points that need to be addressed and improved upon, the whole reason one has metrics and it also if things are going well, drives a message to the business of the value of IT.
Be careful of trying to fit too much information into your task status. As said above, different levels of granularity are required at different times, and often it doesn't all fit well in a single view. You might have a high level schedule that shows the general progress of tasks, but if you need further granularity, that may go on a 2nd layer. I might have a Tier 1 level schedule for a project that shows something off plan. To provide status on that, I might switch over to a Tier 3 that shows the detail level plan of the performing group, supplemented with additional information like who owns it, why it's late, the importance etc. With a virtual dashboard you might be able to "drill down" to the lower levels, or you might have different linked slides on a PowerPoint.
Different types of information are often better served with different views of your project. While you might be able to show the CPI, SPI, performer, and everything you can think of for each task of your whole project on one chart, it starts to become too cluttered. Nobody knows where to look and it loses impact. Unless you are required to provide status in a format that you are expected to hand to someone with no explanation, don't be afraid to verbally supplement the data you are showing, with your additional information while you provide status. If you are required to provide status in a format where it must be read with no explanation, be very careful how you organize and format that data to make it intelligible to the reader.
I would agree the status Kiron listed is enough, and also agree with Joseph that there other ways to measure and report quality.
First of all thanks for your time. I agree with your comment to a point. See as companies accross the world move towards globalization, towards having more remote workers, and also in an effort to reduce costs more automation is now happening. Hence the need of "human resource" profiling.
I give you an example.
Let's say I hire Maxim out of Russia based on his resume and "experience" written on his resume and I hire him as a network engineer.
Then I assign Maxim to couple of network refresh deployments in Europe.
The project he did in Germany took him an extra 10 hours due to a caller id issue he had with the local telecommunications company. Fine 10 hours
Then I sent him to a project in czech republic, now on this project maxim had an issue with faxing and it took him almost 14 hours with Cisco on the phone to correct the issue.
Well, now our software is telling us that there is a lot of extra time consumed in configuration and troubleshooting.
While Thorsten from germany have done 2 similar projects in other parts of Europe and there were no problems, the tech refresh was done within the hours originally estimated.
So...guess what? now we know that maxim may not be the right resource for the tech refreshments.
We would never knew this by having three statuses as part of a task. My job as a project manager is to save money on the project, by being efficient and by being pro-active and not reactive.
I want to be ahead of things, and not react to things when things happens. Hence we know that the task information can yield a lot of information, information that can be use for many things on the project including predicting the outcome of a project.
Just my two cents.
I agree about simplicity specially when it comes to reporting the project status to stakeholders, in this case all of this data is fit onto an intelligent engine and is only used internally.
I guess we dont want our customer to know maxim mistakes which could be understood as lack of experience.
Please login or join to reply