projectified

"Waterfall" is a Bad Way to Refer to Non-Iterative Projects

There are lots of new(er) PM methods out there now with XP, FDD, Agile PM, etc, etc. Most, rightly so, favor an iterative WBS 'design' that has the project going through multiple design\code\test loops rather than the 'old' way of doing a big design\big code\big test loop.

Practitioners of the newer methods tend to refer to the older methods as "Waterfall" PM. I guess this is because the Gantt chart for the old style project looks like a waterfall:

But think about it. What does a Gantt chart look like for the new(er) iterative methods?

It looks like 4 little tiny waterfalls! :-)

So I'm not sure what the 'old' way needs to be called but to call it waterfall is just wrong because the new method looks just as much like a waterfall as the old one does.

So here is the challenge: Email me at [email protected] with your choice for what the 'old' way should be called. (Now all you XP guys have to keep it clean. No bad language)

:-)

I will publish the best ones in a later post.

Categories Should be Single Purpose

Categories in Project Server provide users access to resources and projects. There is a tendency that I have noticed in the field for people to try and get one category to give access to all the projects that a user might need access to within all the roles that user plays in the system. For example:

My Projects. Many administrators see this category and correctly assume that this is the category to which their project managers should belong. But then they try to set the permissions in the category so that it lets the project managers see not only the projects they manage but also the projects on which they are resources. This seems fine in theory but there is an important problem here. The permissions that the project managers need for the projects they manage "Open Project" and "Save Project" are generally more than you want to give a resource on a project. You want the PM to be able to these things on the projects they manage but NOT on projects where they are assigned as resources.

 

 

 

 

 

 

 

 

 

 

But if they have the permissions checked as shown above AND they have access to the projects listed below they will be able to take any project where they are assigned as resources into Project Pro and save changes made to the plan, even though they are not the project manager of that project.

The administrator of the this category over-thought the roles that project managers might fill. This admin tried to get the My Projects category to do more than one thing. A better solution would have been to ONLY check the first box in the My Projects category and then also assign the project managers that might be team members to a group that gave them access to a category where ONLY the second box was checked, giving them permissions to see projects where they are team members. This second category would NOT have the Open Project or Save Project permission.

You can have as many categories as you want, there is no limit. Make them single purpose\single role. If a person is going to fill multiple roles then associate them with multiple categories. If a person is a PM for some projects, a Resource Manager of some resources and also a team member then make sure they get associated with the My Projects, My Resources and My Tasks categories and that these categories are constructed so that they give access to ONLY the items that that specific role would need to see.

Think about Roles not about people when building your security model.

 

 

The PPC Blues

OK. From some emails and some posts from Hal Im thinking that the PPC macros are not done yet. :-)

The macros I posted earlier used the Task Baseline Finish date as the "Promise" date for PPC calculation. However, the "promise" can be revisted on a day to day basis and this revision would likely NOT result in the resaving of the baseline. I think we might want to use an Interim Plan (Project has 10 of them that stores a snapshot of Start and Finish dates at a point in time). This interim plan change be saved and resaved without having to resave the entire baseline. I also think that based on this rapidly changing nature means that the use of the Status Date to use as a threshold might not be as important.

So I will be updating the macros this week and posting them again. (Yes again!) :-)