Newbie question

[Derek]

I'm using Project in a slightly unusual way, and I'm mainly using it because
I have to (organisational reasons - to link to Project Server).

I have no interest in the scheduling side of project. I am using it as a
list of small unrelated items of work for myself and 2 other team members.

What I do want to get out of it is
1) Timesheets (members will be filling in their own via Project Server web
interface).
2) % Complete. I want this completely unrelated to Timesheets. So they
enter the time spent on a project, and the amount it is completed separately.
3) Documentation on each item.

The main problem I'm coming across is that I'm not able to stop the hours
worked automatically updating the % Complete. (Also, since the team members
are using Project Server web access, I can't find anywhere for them to fill
in the % complete).

 

[Brian K - Project MVP]

What I do want to get out of it is
1) Timesheets (members will be filling in their own via Project Server web
interface).
2) % Complete. I want this completely unrelated to Timesheets. So they
enter the time spent on a project, and the amount it is completed
separately.
3) Documentation on each item.

The main problem I'm coming across is that I'm not able to stop the hours
worked automatically updating the % Complete. (Also, since the team
members
are using Project Server web access, I can't find anywhere for them to fill
in the % complete).

You could use the "Physical Percent Complete" to hold your strangely
disembodied metric from beyond the 5th dimension.

Sorry for the sarcasm but I have never understood how people think that %
Complete is NOT connected to how much work or duration has been passed on
the task.

 

[Derek]

The items of work are very small (a couple of days), and the estimates are
very rough at the time of scheduling. In fact the scheduling is fairly
irrelevant to me, and I probably wouldn't be using Project (and Project
Server) if it hadn't been ordered from above.

So when I'm looking at a task that one of my guys is working on, I want to
know how many hours they have spent to date, and how much they have managed
to get done. Since this generally holds no resemblance to the original time
estimate that I made when it was scheduled, I don't want Project making any
assumptions based on the original estimate.

However I do want to be able to compare my original estimates the the total
work later so I can see how bad my estimates were.

I appreciate this method would be stupid in a "normal" project of the sort
that MS Project is designed to handle, but mine is more of a "to do" task
list then a project.

So if you have any suggestions on how best to twist Project (and Project
Server) to my ends, please let me know.

 

[Brian K - Project MVP]

The items of work are very small (a couple of days), and the estimates are
very rough at the time of scheduling. In fact the scheduling is fairly
irrelevant to me, and I probably wouldn't be using Project (and Project
Server) if it hadn't been ordered from above.

So when I'm looking at a task that one of my guys is working on, I want to
know how many hours they have spent to date, and how much they have managed
to get done. Since this generally holds no resemblance to the original
time
estimate that I made when it was scheduled, I don't want Project making any
assumptions based on the original estimate.

However I do want to be able to compare my original estimates the the total
work later so I can see how bad my estimates were.

I appreciate this method would be stupid in a "normal" project of the sort
that MS Project is designed to handle, but mine is more of a "to do" task
list then a project.

So if you have any suggestions on how best to twist Project (and Project
Server) to my ends, please let me know.

Well then you are not far off from what I was thinking. You can still use
the 'normal' method with your project. Just make sure when you ask them
how much they got done (Actual Work) that you ask them when they started
(Actual Start Date) and how much they think they have left (Remaining
Work). The key is to stop asking for % Complete. There is too much room
for error and differing assumptions. Ask for Actual Work and Remaining
Work and Actual Start Date and you not only update the original
(innaccurate) estimate with a new much more accurate one but you also get
what ammounts to % Work Complete by asking how much they have done and how
much they have left to do.

This is how I suggest all the clients I have ever worked with do it.
Though some do it via a more detailed timesheet in Project Server where
the resources enter their actual work on a daily basis. The end results
are the same though. Updated, realistic estimates coming from the people
doing the work while they are in progress and realistic looks at how much
has been done and how much longer it will take based on the latest
thoughts from the field.

 

[Derek]

Thanks Brian

I've looked a little more into your suggestions and it's starting to make
sense to me now. I think this is the way I'll go forward.

Cheers
Derek

 

[Brian K - Project MVP]

Thanks Brian

I've looked a little more into your suggestions and it's starting to make
sense to me now. I think this is the way I'll go forward.

Cheers
Derek

I should not have made it sound quite so simple though. Most people
think in % Complete so getting them to give you other info may not be
easy. It is really the same info but delivered in a way that leaves less
room for different interpritations and less room for errors.

I hope it all works out! It is a long road.

 

[John Sitka]

Derek, you are on a good path here. Lose the %complete.
There is nothing to say that 5% of a task could not take 95% of the total task time.
Why even bother looking at it?


Consider PWA to your Resources as a task list. Their role is very simple.
Record their progress.

Here are the rules.

Go to PWA and record your Actual Work and Remaining Work
on....

Task completion
Task change
When you quit working.

Don't over think that part too much.

You will need to become an expert in leveling.

The linking can work and/or you could build an individual project for each resource.
and/or just use a single project as a resource control panel. The rest of your organization however
will need to become skilled at managing inter project links as master projects do not work in Project
server.

The key to making this work is to think about it correctly and solve the right problems, this can be at odds with reading about
using Project,
or a lifetime of estimating tasks and planning anything.
The core functionality and concepts you need for great results are very simple but they get muddied or misunderstood very easily.

Brian mentions very insightfully...

I should not have made it sound quite so simple though. Most people
think in % Complete so getting them to give you other info may not be
easy. It is really the same info but delivered in a way that leaves less
room for different interpritations and less room for errors.

Some key concepts to your users.

Q. What is a project?
A. A detailed plan of action to complete a deliverable.

Q. Once the planning is done to formalize a project, when is it out of date?
A. Immediately.

Q. As a worker in this company how can your efforts make a strategic contribution to the success of the company in completeing it's
projects?
A. By reporting frequently and accurately the status of my activites with no concern as to original estimates. I know this is the
only way proper early and effective decisions can be made that impact downstream or concurrent projects. Also it provide insight how
best to use my skills and the skills of those around me and allows my focus to stay more on the task at hand. I am happy that I now
feel that my efforts are now part of some global strategy that will help the company and my team rather than engaging in stress and
heroics at a local level requested by myopic management, only to have those efforts pissed away by others.

Your core needs.

A task list
A status recording mechanism.
An identification of significant tasks within each task list (or your small goups set of tasks) that represent some key point
(blackbox) constraint on the bigger system which is trying to get the project complete.

Project Server can provide all of these.

Your small group has a flow to it, as product is created from that flow,
the organization as a whole should be able to dynamically respond to it very timely.

 

[Derek]

Thanks guys

I've got my team to read this. It's making sense to them as well. I'll
have to investigate levelling a little more.

We're getting around the variations by only scheduling 1 month at a time.
Our users priorities change too much to schedule more than that anyway. So
when people look at us as a resource, they will only see the next months
work. This might create problems in the long run, but it should work for now.

Thanks again.

 

[Brian K - Project MVP]

Thanks guys

I've got my team to read this. It's making sense to them as well. I'll
have to investigate levelling a little more.

We're getting around the variations by only scheduling 1 month at a time.
Our users priorities change too much to schedule more than that anyway. So
when people look at us as a resource, they will only see the next months
work. This might create problems in the long run, but it should work for
now.

Thanks again.

The 'technical' term for what you are doing is Rolling Wave planning and
it is something that I suggest to teams that are doing things that take a
long time to do but are highly volatile in nature. I suggest doing this
but with a slight variation. I tend to like there to be some very high
level tasks that represent the work do be done in the later months right
on out to the end of the project with estimates as good as you can get
them. Then plan the next month in fine detail, the month after that in
slightly less detail and so on. Then as you start to plan the next month
(at the end of the current month) you also put more meat on the following
months work so you always have super detail for next month, slightly less
super for the month after than and so on to the end of the project.
Estimates and detail should be refined on a regular interval (maybe every
two weeks) so you are constantly getting the estimates for any given task
up to date with all the new things that the people know about the project
so far. It is not exactly "Agile PM" but it is more agile than planning
the whole 1 year project up front.

Sounds like you are lucky and may have a jump on many others. Most teams
hate the idea of giving more detailed status information. The biggest
problem on average for deploying things like timesheet applications is not
the technology but rather the 'culture' of the team being out of step with
the requirements of gathering detailed status info. Be glad.

 

[John Sitka]

Say a plan is built for a two year project called Main-Production-Plan that assumes infinte resources.
The Main-Production-Plan views your teams contribution as a discreate unit. Say Task-A = 50 hours, this is the 50hrs of progress
you want to track but that 50hr contribution may not take place for 18 months. You as team leader have no idea
of what detail or resources will make up Task-A at this early date. You are simply estimating a Task-A as a bulk task that from
experience you
know will take some 50 hours work maybe 8 hrs per day. Add this task as 50 hrs work and put it in a logical sequence to the best of
your ability.
That 18 month projection may be unknowable; what's going to occur in the interm? but there is nothing wrong with planning/reporting
what you "DO" know and "NOT" reporting what you don't. If at this time you know six months of activities then Task-A is to be done
after that 6 month run. Task-A can follow at the end of 6 months as a logical model. I think this is a better concept that
artificially constraining the 50 hrs task at some date 18 months out. As far as the Main-Production-Plan is concerned you are not a
constraint, they need something "DONE" in 18 months, You only have insight or are aware of 6 months into the future, thus the
Main-Production-Plan is constrained in actuality only by THEIR logical model and at this early stage can be operated on the
assumption that you will have the deliverable for them probably way ahead of when they need it. Their link to your
reporting/planning project does not at this time seem to come into play. That is all that can be know right now so go with it.

Now the trick, you have that Task-A 50 hrs as a single task. As you come to know the requirements of that task start adding detail
to it in a up and to the left backwards sequence. If you now Joe will work 10 hrs on part of that 50 hrs add a new task for Joe as a
perdeccesor to the original 50 hrs (abstracted) task and reduce Task-A from 50 hrs task to 40. The original 50 hrs task must be
maintained and it will eventually become so small as to represent a point in time. Task-A was 50hrs (no resources) becomes Your
control Project.Component-1 10hrs(Joe) followed by Task-A (no resources) 40hrs = original 50 hrs.
Reapeat as needed. That will change Task-A from an abstracted task idea into an end point of the original 50 hours task, that
single 50 hrs task has matured into a set of tasks leading up to it, a task completed marker.. The production plan from day one used
that 50 hr task as a predecessor and constraint in their planning. As you added detail and tracked it that link is maintained and as
the 18 months approaches, Main-Production-Plan project became more and more responsive to the dynamics of your tracking. They linked
to Task-A 18 months in advance. It still exists in you project.

like this

Your control Project.Components-Complete = 50 hrs Predecessor to Main Production Plan.Fit and Bolt on Components = 10 hrs

Your control Project.Component-1 = 10hrs Predecessor to....
Your control Project.Component-2 = 10hrs Predecessor to..
Your control Project.Component-3 = 10hrs Predecessor to..
Your control Project.Component-4 = 10hrs Predecessor to..
Your control Project.Component-5 = 10hrs Predecessor to..
Your control Project.Components-Complete = 1 hr <-- (originally had value 50 hrs ) still is Predecessor to Main Production
Plan.[Fit and Bolt on Components] = 10 hrs

I wish Project had better active linking and calculation but it is flawed as it is not cannot calculate what isn't open. It keeps
the planning and tracking as two distinct modes. but the planning can still be responsive to ongoing tracking. Pretty good situation
really.

Pretty rosey situation but lets see what happens in 6 months....

Well you have added many tasks to the original 6 month project that obviously came well before Task-A. Task-A gets pushed out more
and more until it becomes the time you believe to do some actual work on it. Main-Production-Plan project manager observes this and
says
"Hey originally you said that that Task-A would be done.", he baselined.
Your response is "yeah....So, Your original requirements of my team was that it be complete in 18 months I will still deliver easily
on that."
"But...but...but...."

No Buts.

Your plan decision making feeds off his project, his project feeds off your project. There is no other way to do this. If his
Project accelerates it was both of you that would need to come together and observe the progress, and act as needed. If
Main-Production-Plan had accerated, you should have taken a look at it (once a week for example) so you could go to the cottage on
the weekend knowing that there will be no surprises that will interupt your teams flow. Main-Production-Plan guy should have let you
know that Main-Production-Plan was accelerating at an incredible rate, and that Task-A may come into play as a constraint on
Main-Production-Plan. It'a a long journey because it represents a way of dealing with stuff that was internally calculated by most
people and exposes it for what is really a very simple perscription or set of steps. Amazingly difficult to convince.
(Use metaphors to help the thought process. I windsurf so picking my way through waves or chop, linking gusty winds to keep planning
is a way to maintain flow. Each resource/teamt/whole company benefits from flow. Link things together smoothly without starts or
stops. Anticipate the next gust (beating estimate) or lull (under perfomance) and make smooth transitions from one task to another.
Queing theory backs this up, personnal work experience shows that focused effort produces the most enjoyment and best results,
creative solutions, or whatever.

The creator of Main-Production-Plan is going to have to get on board though, He will probably have a plan full of non-calculated
date constraints,
and blatant time wasting overestimates. Which in the real world means basically he has planned for failure, but that is another
investigation all together. ;-)

 

[Steve House [Project MVP]]

Remember MS Project DEFINES % Complete as the percentage of the total
duration that has passed. So when a task is 95% Complete, 95% of the total
time the task requires has gone by by definition and it can be nothing else.
But this says nothing whatsoever about the percentage of the total required
work that has been completed or the amount of physical progress that has
been made towards the creation of the deliverable. True, updating the task
to 50% complete also sets % Work Complete to 50% by default because in the
majority of cases work is spread out flatline and proceeds at a constant
rate for the duration of the task but that's by no means universal to all
tasks. The Tools Options Calculation settings have a check box "Updating
task status updates resource status" that sets or break the linking between
the % Complete and % Work Complete where updating one also updates the other
so you can have Project treat it your prefered way. Of course when you
break the link it doubles the amount of data you need to enter when posting
progress but sometimes you really do need to update the two fields
separately.
..