I was wondering what methods people use to track a project's progress. We have set up our controls projects in MSProject, however it has proven very difficult to ascertain the completeness of individual code pieces. If you ask the individual writing the program, the progress starts at about 30 percent and quickly progresses to 90%. It is not uncommon for the status to stay at 90-95% for longer than it took to get there. I am guilty myself of not being able to accurately judge 'where' I am in the completeness of a program. I have thought about adding the 'lines of code' metric and see if it helps. Any suggestions? BTW, I am dealing mostly with medium size controls projects. Usually 1-3 PLCs with 1-5 HMIs.
Eng-Tips is the largest engineering community on the Internet
Intelligent Work Forums for Engineering Professionals
-
Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Tracking Project Progress 2
- Thread starter madkungfu
- Start date
-
1
- #2
Been there, done that. Know your pain ![[wink]](/data/assets/smilies/wink.gif "[wink] [wink]")
.
My control programs usually sat at the 30% level until the project neared the end, then suddenly shot up to 95%. If the programs are written in modules, it's a little better. Batch-type programs are better still.
Counting lines of code doesn't help much, UNLESS it's a standard program or template.
How do you test your programs? Are they subject to a Factory Acceptance Test (FAT)? Those are good mileposts.
As to the programming, I followed the progress in stages:
*Definition (MOST IMPORTANT - know the required scope.)
*Planning (The programmer should have an idea of how he/she is going to meet the scope.)
*Coding (or Keyboarding - very subjective.)
*Review/Testing (a second party review of the code perhaps, or some quick tests of logic.)
HMIs are a lot easier, assuming you know the number of screens you want. You can keep track of the number as they are initially programmed, tested, and finalized.
Hope this helps.
.My control programs usually sat at the 30% level until the project neared the end, then suddenly shot up to 95%. If the programs are written in modules, it's a little better. Batch-type programs are better still.
Counting lines of code doesn't help much, UNLESS it's a standard program or template.
How do you test your programs? Are they subject to a Factory Acceptance Test (FAT)? Those are good mileposts.
As to the programming, I followed the progress in stages:
*Definition (MOST IMPORTANT - know the required scope.)
*Planning (The programmer should have an idea of how he/she is going to meet the scope.)
*Coding (or Keyboarding - very subjective.)
*Review/Testing (a second party review of the code perhaps, or some quick tests of logic.)
HMIs are a lot easier, assuming you know the number of screens you want. You can keep track of the number as they are initially programmed, tested, and finalized.
Hope this helps.
ChevyBuilder
Mechanical
The more tasks and milestones the better. You need constant feedback from all the do-ers. Software might be done but can not be implimented until installation is done, can't do installation until panel production is done, no panels before engineering and purchasing. These major tasks make milestones, milestones with several sub tasks and dependancies. The feedback from the do-ers is the hard part...even if your the only do-er.
I am a new comer for the project management team.
So, what can I do for manage several project at once.
I do know using MS project for keep tracking.
But
How can I setup a feasible schedule before starting the project?
Or what should I do before starting the project and scheduling the project?
So, what can I do for manage several project at once.
I do know using MS project for keep tracking.
But
How can I setup a feasible schedule before starting the project?
Or what should I do before starting the project and scheduling the project?
HamishMcTavish
Nuclear
I think ChevyBuilder hit the nail on the head, you need a good work breakdown structure!
Not sure if your issues are because it is software, but surely when you generate the definition of requirements for your project you should be able to define acceptance standards?
Final acceptance will come from your customer (whoever that is) based on the acceptance standards that they SHOULD have agreed. It may be that they will accept your 95% complete (as long as they can use it) along with a plan to rectify any defects outstanding.
No more things should be presumed to exist than are absolutely necessary - William of Occam
Not sure if your issues are because it is software, but surely when you generate the definition of requirements for your project you should be able to define acceptance standards?
Final acceptance will come from your customer (whoever that is) based on the acceptance standards that they SHOULD have agreed. It may be that they will accept your 95% complete (as long as they can use it) along with a plan to rectify any defects outstanding.
No more things should be presumed to exist than are absolutely necessary - William of Occam
Thw WBS is part of the solution. The other part is to keep meticulous records of previous projects and the task durations incurred.
What this means is that you'll need to have some sort of timecard system that allows you to have sufficient granularity into time charges that correspond to the WBS items.
Once you develop the database, you can use engineering estimates until your database is fleshed out, you can then generate your WBS and then estimate the projected costs based on similarity in scope to previous projects. Note that your record keepping should also detail the hows and whys certain tasks did not meet projected costs. This allows you to calibrate your team members' abilities to accurately estimate costs.
This is, of course, the ideal solution; I've yet to work in an organization that was that disciplined.
TTFN
What this means is that you'll need to have some sort of timecard system that allows you to have sufficient granularity into time charges that correspond to the WBS items.
Once you develop the database, you can use engineering estimates until your database is fleshed out, you can then generate your WBS and then estimate the projected costs based on similarity in scope to previous projects. Note that your record keepping should also detail the hows and whys certain tasks did not meet projected costs. This allows you to calibrate your team members' abilities to accurately estimate costs.
This is, of course, the ideal solution; I've yet to work in an organization that was that disciplined.
TTFN
-
1
- #7
One thing I do at the outset of any project is to define what the "percent completes" actually mean in terms of the work being done. It helps to get everybody on the same page.
I agree with ICMan's milestones but I'd add one between "Planning" and "Coding" for flow charting/pseudo code/logic diagrams. I guess you could lump this in with either of the others but to me, it's a separate task.
I also agree with ChevyBuilder - Detailed WBS is all-important and "the more tasks and milestones the better."
I agree with ICMan's milestones but I'd add one between "Planning" and "Coding" for flow charting/pseudo code/logic diagrams. I guess you could lump this in with either of the others but to me, it's a separate task.
I also agree with ChevyBuilder - Detailed WBS is all-important and "the more tasks and milestones the better."
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question