projectified-old

Microsoft Offers RSS for the Knowledge Base...sorry KBAlertz!

Microsoft now offers RSS feeds for it’s Knowledge Base…Finally!

I have been using KBAlertz for this. Not sure what this will mean for them.

via Scoble

Project Management Systems Don't Kill Project Knowledge, Bad Project Managers Kill Project Knowledge

Jack Dahlgren talks here about the perceived dangers (not ‘evils’ as I said earlier. Sorry Jack) of project management systems like Project Server that use tools like timesheets to gather status information. He also points to Glen Alleman’s post here about the same subject.

Both are basically saying that systems like this are bad because they automate the interaction between project manager and team member and are not as good as face to face interactions between the PM and the team. They are saying that such systems are bad for teams because they do not allow for the transfer of project knowledge or “project wisdom”.

I could not agree more with both Glen and Jack. HOWEVER. the big problem with this is that both Jack and Glen are assuming that teams that use such software never speak. They seem to be assuming that the PM never has any meetings with the team and that the PM never goes and talks with the team. Any team doing this is just flat out wrong. No caveats. No exceptions. I will put it in bold print so there is no mistakes:

Any project manager that expects an Enterprise Project Management application like Project Server to be the only avenue of communication between themselves and their team is not only wrong, they are TRAGICALLY WRONG!

It is not the software. I can tell you with some confidence having worked many times with the team that designed Project Server that it was not designed to replace face to face communication between Project Manager and Team. What Jack and Glen are describing are organizations that are fundamentally broken. The software just helps them be broken faster.

In my work deploying Project Server with QuantumPM we (myself and the other consultants at QPM) were always very clear about the GRAVE dangers of assuming that Project Server timesheets would replace or fix broken lines of communication within the Project Team.

Glen says that PMs should be asking “…simple questions - what do you mean when you say "we're making progress”. I agree. Project Server (and other tools like it) allows for the efficient collection of the progress information in the detailed kind of way that things like Earned Value and many organizations demand (timesheets) This allows the PM to spend their face to face interactions asking the good questions instead of collecting Actual Work numbers and allows them to ask these good questions armed with the data they might need to ask them well.

So in closing: Project Server does not kill process and interaction, bad PMs do.

New Project Server Book Coming!

My old friends at QuantumPM wrote a book about Project Server! It should hit the street mid-June (so says Amazon!) It will be an excellent resource for those deploying or working with Project Server 2003. I have read every page at least once as I was the technical editor for the book and I can assure you it will be a GREAT book!

If you are thinking about deploying Project Server or already have it and want a great reference book you should go right over to Amazon and order up a copy of Microsoft Office Project Server 2003 Unleashed right away! :-)

Disclosure: While I was compensated by Sams Publishing for my work on this book that compensation has been completed and I have no financial interest in how many copies of this book are sold. I am promoting this book because I have read it and it will be well worth every penny of it’s price for those people working with Project Server.

 

The Secret Life of Scope Cuts

Over the past few weeks I have been talking with some old co-workers about our experiences with our old clients. One of the things we talked about was how rare it was that project managers really examine closely the real impacts of cutting scope. By this I mean that they often feel that, for example, if they cut a set of tasks from their project that is estimated to take 30 days that this means they actually cut 30 days from their project. While this might be true for things like a construction project it does not always work out for things like software development projects.

At first thought it sure sounds good though. You have a feature that when you add it all up will take 10 or 20 days to develop. You cut it from the project in an effort to shorten your project and you feel pretty good. (Well as good as you can ever feel after you cut a feature you obviously at some point really liked!) Then you feel pretty flush and you figure you can now shorten your QA time in the schedule because you now have fewer features to test! This is getting better and better. Right? Well maybe not.

The thing that I have noticed people forgetting is that sometimes it takes time to NOT finish a feature. How is the feature or code you are pulling from the product linked or related to other features in the product? Do other features or parts of the application depend on code you plan on pulling or not finishing? Will it require you to rewrite other code to deal with the cut you want to make? Was the application designed in a way that will make this hard or easy? If you decide that you do need to make changes to other code to compensate for this cut has that code already been tested? Will you need to retest code because of this cut?

You see what I’m getting at here. It could end up costing you more time to cut the feature than cutting it would save you! Isn’t software fun?

 

What Kind of Work Do You Do?

Hugh over at gapingvoid posted this drawing in a post today.

 

 

I have not decided yet if he intended that being a commodity was a good thing or a bad thing but it reminded me that I always have a difficult time describing what I did when I was at QuantumPM (or at Pacific Edge too for that matter). At both places I was a project management software consultant (less so at Pacific Edge but that was the general gist of it) I have been living in my community for about two years now but it is a pretty tightly knit small town kind of place so we are still breaking in. I get asked a lot about what I “do”. They know I work from home from their kids talking to my kids but where I live that is kind of odd. (Most families here are related to the timber industry, petro-chemical refining or construction.) How do you explain to someone, briefly, what a project management software consultant IS when their biggest interaction with a computer is likely watching their kids do AOL chats or maybe checking email and surfing the occasional web page and they don't have the lightest idea what project management really is? (Hell, I know executives that have a hard time getting what PM is!) The harder I try the more their eyes glaze over. In the end, when someone asks me I just say “I work with Computers” and that is enough to filter out the ones that would not understand. If they just nod and move on to the next question then I have my answer and they have enough of an answer for them. If they ask for more specifics then they are a computer person and I can get more detailed. Though this problem got WAY easier when I went to work for EA as a trainer. Now I just say I’m a senior corporate trainer for Electronic Arts and the conversation goes straight to video games and the problem is solved! :-)

 

What this brings up for me are the questions: What does it mean if nobody gets what I do? Does it mean I'm not good at explaining it or just that it is kind of arcane and naturally hard for the non-computer, non-PM person to wrap their minds around? What does it say about it’s value as a product, if anything?

 

This in turn gets me thinking about how it is even hard to get our customers to really understand what we do. I think there is often a gap in what we think we do as consultants (or what we want to do) and what we get hired to do. We think of ourselves as people helping organizations and teams and individuals get better at managing their projects through examination and refinement of processes. But all too often that is not what we are hired to do. We often get hired to install Project Server or some other enterprise application (PM or otherwise). The true role of the (good) consultant is to do what is best for their clients by bringing knowledge and experience to bear on the client’s problem. But what if the client lacks the understanding of what their real problem is? They think the problem is that they don't have good PM software tools (or other enterprise application) installed and that alone is what is holding them back from a higher greatness as an organization. But their real problem might be (and often is) that they do not have the right kind of communication, organization and management processes in place to support good project management (or other ‘management’ in the case of other enterprise applications).

 

Trust

Hugh at GapingVoid has some interesting things to add to Sigurd Rinde’s (at Forthcoming) post about Trust which I think, at least for me, relates to their earlier comments on culture and technology which I talk about here.

Sigurd says:

Fact #1:

Trust is what makes a company exist. Without trust no customer, no investors, no suppliers, no place in society.

Fact #2:

Transparency equals trust. That simple.

To which Hugh adds:

Transparency's a tricky one. Transparency relies on human beings, and human beings are generally a frickin nightmare.

And

At the company you work for, how afraid is the average person of making a mistake? Of not being right? Of backing the wrong horse and being found out later?

And then there's your answer. The less afraid he or she is, the more transparent your company can be, with itself and with the outside world. The more afraid he or she is, the more opaque you'll have to remain.

I think about trust, in my work as a project management process and software consultant, in a more specific way. In my post about Culture and Technology I talked about trust with regard to project team members filling in timesheets. For the technology to be of optimal usefulness to the organization team members need to feel comfortable putting bad news in their timesheet entries. When they use the timesheet system to tell the project manager that they worked 30 hours this week on a task that they were scheduled to work on for 40 hours can they TRUST that this info will not be used to fire those that are not working up to the plan? (This is assuming that they are working short of the plan because they are working hard but other things are coming up and disrupting them. It does not apply to those that are short on their plan because they are just blowing work off.) There are too many organizations that put together project schedules that assume that a person that works an 8 hour day will be productive on the project for a full 8 hours a day and when they are not (which they cannot possibly be) they look at the team member as if they are to blame for the task or project for being behind schedule.

This example is one that shows cultural and process ‘issues’ and in many cases the technological issues of not understanding the software they use to create the schedules. But at the ground level it is a matter of trust. Does the team trust the project manager (or “management” as a collective) to use the data in what they (the team) feels is responsible and in a larger sense does the team trust the project manager to be doing the “right things” in planning and modeling the project (even if the team does not actually, technically know what the right thing is)?

I think that Hugh and Sigurd should write a book together! These guys are great! Though I guess, in a way, their back and forth could later be seen as a sort of virtual book. I think there is an interesting point of exploration there concerning how to compile related posts from across different blogs into a virtual ‘whole’. But that is for bigger brains than mine to figure out. :-)

VERY Cool PowerPoint Multimedia Tools

http://www.pfcmedia.com/

If you use multimedia in your PowerPoint presentations then you should check this out. It adds to PowerPoint the ability to play DVDs, display video from live webcams and play url based streaming media files directly from inside your Presentation. Just the streaming media part is cool enough. This means that you could send you PPT to someone and they could view the video without having to be sent that HUGE video file! Very Cool Stuff.

Technology vs. Culture

Frank Patrick talks here and here about the difference between a technological solution and a cultural solution based on a thought on GapingVoid.

I could not agree more. The word ‘Culture’ comes up a lot when I do deployments of Project Server. Obviously Project Server is a technological solution but I go to great lengths to make sure that the people I talk to about it know that it is just part of the “nutritious breakfast”. When I worked for QuantumPM we all did our best to fix the all to common misunderstanding among some clients that installing Project Server was going to suddenly make them better at doing projects. Sadly, it did not always work. Technology is easy. Project Server 2003 is pretty darn easy to install. Configuring is more difficult but only because it requires an analysis of the culture of the organisation and of it’s processes. Here before the tool is even ready to be used the importance of culture is right there having an effect on the success of the technology.

Timesheets\task status was the place where the importance of culture was the easiest to get across to clients. Collecting status via an electronic timesheet (like the one in Project Server) seems, on first glance of the client, to be pretty simple: Tell your team members they should go to a web page and enter their time each week. No problem, right? WRONG! What if they have never had to do this before? What if they think you only want this to see who is not putting in ‘enough’ hours in a week? What if they don’t trust the managers to use this info in a way they agree with? These are all important cultural factors in an organisation that need to be addressed before rolling out a timesheet type solution. I remember first seeing this when I worked at Pacific Edge Software. We had the same problem with our clients there as many Project Server clients: team members resist the deployment of timesheet type status collection methods because the organisational culture was one of mistrust and fear of what would be done with that information.

I always try to do my best to correct my clients when they refer to what we are doing as “installing” Project Server. Installing Project Server is something that happens but it is not why I’m there (even if is why you THINK I'm there). What companies like QuantumPM are doing is project management process improvement that just happens to install some software in support of the larger deployment of new processes (read process as ‘culture’).

There is a HUGE difference between ‘installing’ and deploying. Installing Project Server takes about an hour or two. Deploying Project Server as a part of a larger process\culture change program takes months if not years of ever evolving changes, tweaks and improvements.