locking up certain tasks in a template

[schemr]

hi,
i am creating a template for all the project managers to use and i was
wondering if there was a way to "lock up" certain tasks or cells so the
project managers wudnt be able to remove them from the project. this is to
make sure that ALL Projects have these set tasks that need to be in every
project. thanx

schemr

 

[Reid McTaggart]

No, you can't really lock down a non-enterprise tempate. But you can use
custom field formulas to create indicators that turn on if such tasks are
deleted. You also could create a macro that tests for the existence of the
required tasks.

 

[Jan De Messemaeker]

Hi all,

I'm afraid you cannot make a custom field formula that uses data from, or
the existence of, an other task.
HTH

 

[Reid McTaggart]

The solution I have in mind does not require referencing other tasks, only
other fields.

Here is a simple example of one approach, which uses two Custom Number
Fields to test for the existence of a task named XYZ. It could be extended
to test for the presence of several tasks:

Number 1 -- Rename to Task Name Test. Formula: IIF([Name]="XYZ",1,0). Set
Rollup to Sum.
Number 2 -- Rename to Name Test Rollup. Formula: [Number1]. Set graphical
indicators: Equals 1 is Green Does not equal 1 is Red.

 

[Steve House [Project MVP]]

Just curious - why would you even want to do that since it's the project
manager's job in the first place to make the decisions about what needs to
be done and in what manner to bring the project in on schedule and within
budget? The job is called "project MANAGER" not project clerk. One can't
manage without the decision making authority to decide what needs to be done
and what doesn't and a PM is decidedly a manager in the truest sense of the
word. If you need to insure that they include certain administrative items,
etc, a meeting or a memo should be sufficient. The project manager is the
captain of that ship responsible for the success of the project and one
can't properly manage unless responsibility and authority are commensuate.

 

[Reid McTaggart]

Not to answer for scherme, but there are some situations in which requiring
certain tasks makes sense, and making it easy to confirm the existence of
such tasks reduces the burden on PMs or Administrators.

One situation is where there are enterprise-wide reporting standards. A
related situation involves external recording and reporting systems that rely
on specific tasks.

One of my past clients has scores of government-funded projects underway
concurrently. Each project manager must ensure that specific reports and
forms are submitted to the government according to a precise schedule.
Individual PM failures in the past have resulted in delays and penalties
costing millions of dollars. Certainly, it is the PM's responsibility, but
the cost is born by the organization, which rightfully wants to help PMs
avoid further such mistakes.

They now use a system of macros and indicators to ensure that certain
critical tasks are included in every plan, and to send notices in advance of
the finish or start dates of those tasks. They also have external systems
that query the database for these special tasks and create reports for
Program Managers and other stakeholders.

FWIW.

--
Reid McTaggart
EPM Architect
Microsoft

 

[Steve House [Project MVP]]

No disagreement there - more commenting on the LEVEL where a Project
Manager's role should be placed in the organization. A PM, IMHO, is truly a
manager, a decision maker and tactical planner, and not just an
administrator. In miltary parlance, he's about the level of a Lt Colonel or
a full bird. Not trusting him to know what reports need to be generated for
whom and to decide how and when to do them seems to be demoting him down the
the level of 2nd Lieutenant, if not company clerk a la Radar O'reilly. If
you view the organization and the project as an hourglass, with senior
managment, the board of directors, and the stakeholders/customers in the top
bulb while the project teams and resources are in the bottom bulb, the
project sponsor and the project manager sit right in the narrow part of the
neck, the conduit through which everything project-related flows and the
point of final decisiuon making authority and responsibility. Harry
Truman's "The Buck Stops Here" plaquard sits on their desk. If someone in
your PMO is telling the PM's what reports to generate via a template that
they must follow, it wopuld appear that the person who created the template
and decided what needed to be on it is really the project manager, not the
person using it.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[Jan De Messemaeker]

Hi,

It all depends on the project.
If it is one of the 95% less-than-5-people projects the project leader is at
best a sergeant, not even an officer.
It it's a multi million dollar euro project he's more likely to be a
colonel.
But most of my clients run scores of small projects and they need a common
reporting, so NO WAY can a project leader have a say in reporting. He will
be told what is a milestone and how to use the baseline, for instance.

Chaos can be fun but iit is rarely productive.

 

[Gary L. Chefetz [MVP]]

Steve:

Coulda, woulda, shoulda. Your comments seem to be inexorably pegged to the
"ideal-state" of project management; they're reasonable fodder for academic
discussion but rarely in touch with the real world. To suggest that working
within a standardized framework of reporting somehow denigrates the project
manager's status is utterly preposterous when the PMBOK, itself, is nothing
more than an enhanced process map; a framework for managing and reporting.
Following your logic up the line, one must conclude that the only people who
are truly project managers are the framers of the PMBOK.

In the real world, I see many project managers fail because they're too busy
trying to be the PM they were taught to be, rather than the PM they need to
be.

 

[Steve House [Project MVP]]

Not at all, Gary, there's nothing wrong with working within a standardized
framework and accepted procedures. Training in effective methodologies and
professional standards is part of the educational process of many
professions - accounting, law, medicine, surgery, forensics to name a few -
and I don't see project management as any different. The problem as I see
it arises when the project managment role is pushed down the organizational
heirarchy in such a way that it leads to a disconnect between the project
manager's responsiblities and his or her authority to make the decisions
required to achieve those goals. I've done classes, for example, for clients
in the health care industry where hospital ward clerks and charge nurses
were given the designation "project manager" and sent to classes in MS
Project. Yet they had absolutely no authority to determine or even the
ability to find out what tasks were required, what resources were deployed,
what timeframes were required or "nice to have" or even possible, no access
to cost data, fundamentally no real management role at all. "Project
management" was simply a clerk collecting information on what the resource's
bosses expected them to do and when they were expected to do it, and
tracking whether they did it. When a PM is handed a template of the
required project framework and told to use it without their having any input
into whether it should be applied in the instant project, their role is
headed in that same direction regardless of their title. The client's need
for a certain reporting interval, etc, can and IMO should be handled as part
of the project's reporting plan, the development of which is part of the
PM's role in during the project inception phase. Certainly the PM shouldn't
ignore the requirements of any of the stakeholders, but the plan shouldn't
be handed to him as a fait accompli with mandatory compliance either.
Determining the reporting requirements in consultation with senior
management, the clients, and other stakeholders and incorporating them into
the overall project strategic plan is so fundamental to the role of a
manager that it shouldn't be left to SOP. Guidelines yes, but templates,
no. As point man for the project, the PM is the one that should be
consulting directly with the client regarding their reporting needs and not
simply following a predefined procedure.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

 

[schemr]

ok guys, thanx a lot for ur input into this matter......the real reason that
me and the upper management wanted to implement this was for the reporting
system. we wanted to have consistent reports from each and every PM hence if
we are able to have certain critical tasks in every project, there will be
consistency. so if any1 has a good solution for this and know about
it....please guide me.

schemr

 

[Steve House [Project MVP]]

Well, a project template can show tasks should be included and what reports
need to be generated and when they need to be done viz a viz the other tasks
in the project but it will not help with making sure the form those reports
take is consistent from project to project. You would need to create some
document templates in MS Word or similar product to do that. That's not to
say you can't insert hyperlinks in the project plan associating the report
generation tasks with the document template for the report content and in
fact a set of standardized corporate-level document templates and models for
the required reports is not a bad idea for any organization, just to make
sure everyone is on the same plate

One of the problems you face is that MS Project assumes the project manager
is the one who - in consultation with senior management, the clients, and
other stakeholders -decides what needs to be done within what framework and
how it is to be accomplished by whom. As such, the fact that you put
certain tasks into a standard template that you give your PM for him or her
to use in designing the project doesn't create any guarantee that they will
actually keep them there or use them. There's no way to lock them down so a
PM can't remove them since by definition it is the PM that decides if they
belong there in the first place. If someone can change anything in the
plan, they can change everything - it's an all or nothing deal. The only
thing you can do is tell them that the policy is that they must include
items X, Y, and Z, but there's nothing you can do to force them to do it
other than disciplining them if they don't. On the plus side, if they are
high enough in the heirarchy to actually BE a project manager, they're high
enough to understand and be cooperatve with policy and not require
hand-holding and oversight to insure they implement it. "Project Manager"
is truly a management function, not just an administrative one, and the best
way to insure consistency in the reporting process is to include them as a
group in the process designing the reporting policy SIOP in the first place
so they all understand it and buy into it.