projectified

Timesheets. Yes you REALLY do need to fill this in! Please?!

I hear lots of push back on the idea of having resources submit timesheets. “They are too intrusive.” “They take too much time” “I don’t want my people thinking Big Brother is watching” I understand that these concerns are common but I have trouble with them just the same.

You are a project manager. Your job is to make sure that sets of tasks called projects get done on time, within a budget and produce a product that meets a specific quality standard. To do this effectively you need a few things from your resources. You need them to do their work well and as quickly as possible. That by itself would be enough if the project was one or two tasks being done by one or two people. Some projects are that small and simple but most are not. For the larger projects you need one more thing. You need to know that they did the work, when they did it and at what rate you can expect them to do the work that remains. You need this because your project is likely NOT just that one resource working on a task or two. It is likely many resources working on many tasks that are interconnected. And you boss is not happy with the answer “some time in the future, er, maybe” to the question of when the project will be finished. You need to know when to tell the team of testers to be ready for the code because your code is not the only code they will be asked to test so they need to know when to clear the test lab for YOUR code and when to hold off the other 5 PM’s chomping at the bit for your lab time. You need to tell the tech writers, the trainers, the packaging and shipping people and the sales people (dear God do not forget the sales people) when they can expect to start their part of your effort. So your nice busy resources are not in a vacuum. It is not realistic for them to expect that they can just hide away and do their work without being asked a few things about it. They need to communicate to you, the PM, when they finished the finished stuff and when they expect to finish the unfinished stuff. It is that simple.

Now the VAST majority of resources do this now, even the ones in the same companies that balk at setting up timesheets. That is the irony here. Resources and PMs already do this (for the most part). They just do it in ways that you do not notice because they are communication methods that are quite and mostly untrackable. (which is bad). They give status over the cube wall or at lunch during asides to other conversations. They give status 2nd and 3rd hand through coworkers. They give status on post it notes and in email. It is all very gray, very imprecise and, here is more irony, very time consuming. These existing methods end up taking more time. Of course I have no Harvard Business School study to back this up but trust me. It takes more time. :-) The PM gets these stealth status reports from all the various sources and of course can only get about an ounce of usable data from the 5 pounds if ‘stuff’ in them all. So the PM goes and tries to get the details. Time. Time. TIME!

Would it not be more simple for the resource to take about 10 mins a week to fill in a timesheet and press a button? Pick a timesheet. Any timesheet! I don’t even care if it is Project Server. (Well OK I do care. It should be Project Server but you get my point!) There it is. A page with a list of all my tasks grouped by the project they are in. Then there is a grid. Sunday – Saturday. I enter the number of hours I worked on each task on each day. Then for each task I update the number of hours of Remaining Work. This is the important part. How many hours of work do I think are left before I will be done with this task? Is a more important question ever asked of any resource? Tell me, the PM about how long you think it MIGHT take to finish. Nothing case in stone mind you. PMs are very good at being flexible with estimates. We make our livings asking other people (hoping anyway) will be flexible with the ones WE give!

10 mins a week is all you will be asking of your resources. They are grown ups. They can handle it. Explain to them what the impact is of you knowing this information. Tell them stories of cohesive teams all working in harmony. The Test Lab being ready right on time, embracing your code, helping it grow! :-)

Make your resources understand that you NEED this information. They have it. You need it and you have this nifty little web page called Project Web Access that will even help them send it to you. It is already info they give you. You just need it typed into these cells rather than given to you across the lunch table.

The Downside to being at the Front of the Pack...

...the rest of the pack snipping and biting at your heals. :-)

As with any competitive situation in business your competitors are rarely accurate when they describe your functionality to potential customers. I have heard tons of claims over the past year about Project Server that range from the honest mistake to the sadly misinformed to the outright lie.

Honest Mistake:
Project Server 2003 REQUIRES Windows Server 2003.
I can see where people get this one. Windows Sharepoint Services must run on a Windows Server 2003 machine. So if you will be using Project Server 2003 with WSS then you do need to have a machine running Windows Server 2003. But even in this case the machine where Project Server 2003 is running can still be Windows Server 2000.

Sadly Misinformed:
Project Server 2003's licensing is cheaper but it has "hidden" costs of SQL CALs that make it more expensive.
Im not 100% sure if this is people just not knowing or trying to be tricky. Sure Project Server requires you to own SQL CALs. But so will 75% of the other PM solutions out there and 20% of the rest will require Oracle licenses (the rest run on MySQL or some other open source db or another). The database has to be served by something!

Outright Lie:
Project Server does not have a web services backend to allow for customization.
OK in fairness this MIGHT be just a function of being misinformed. But someone in the PM software business would have to have had their head firming planted in the sand to have missed the FACT that Project Server has this thing called the PDS (Project Data Service) that is a SOAP/XML web services API. Sure it has not exactly been advertised on the Super Bowl but you would have had to try hard to miss it if you were researching new features of Project Server 2002 or 2003.

The Moral:
If you are evaluating Project Server or are just starting to look around at PM software do your own homework. If you want to know about Primavera's solution DO NOT take MY word for it. If you want to know about Project Server do not take the word of a SystemCorp sales rep. My opinion is certainly valid when talking about what Project Server can and cannot do. But my opinion of PlanView’s product is not so reliable. :-)

Do you own research. There is nearly 2000 pages worth of deployment guides, installation instructions, administrator guidance, training materials and Software Development Kit documents up on the Microsoft website about Project Server 2003. Now Im not suggesting that anyone go read it all. But I am saying that if you want information about Project Server there is no shortage. Nobody can accuse the Project product team of not sharing.

Stealth Causation

This was just freaky. I just finished doing a Project Server 2003 installation in Dallas. It went pretty well until I was about to leave. I had been testing and doing some early configuration of the system and everything was working great, including WSS. But today at 11am it stopped working. It was throwing tons of errors in the event log about how it could not connect to the database server PROJSVR01. I could open the admin page for WSS but could not edit any settings. It said that it could not find the database!

Now we had done NOTHING to the server. At all! It worked for 2.5 days and suddenly nothing! Really! I swear!

Then after like the 400th time reading these error messages the IT guy notices that PROJSVR01 is NOT the name of the server where the database is located. The name of the server is PRJSVR01 (PRJ not PROJ). Sure enough I look on the one page in the WSS admin page I can edit and sure enough the wrong name is there. It has PROJSVR01. The really freaky part is that nobody edited this value. It took me 10 mins to remember where the hell it was and the IT guy REALLY did not know where this setting was! And it had been working just fine for 2.5 days! Any thoughts before I give it away?

I had mistakenly entered the name of the server wrong when I extended the virtual server. But how is that possible you ask? Doesn't that page validate the server name and then even try to connect to that server with the username and password you supply? Yes and it worked just fine and that is why the system worked for 2.5 days. WSS was accessing the server just fine with PROJSVR01 and Project Server was accessing it with PRJSVR01!

Here is the really cool part. About a week before I got there the IT department built the server. It's name was PROJSVR01 (notice PROJ). Then they changed the name to PRJSVR01. The reason that everything worked was that the WINS and DNS servers on their network still had entries for the OLD name. I just happened to mistype the server name in that page in WSS so that it equaled the name that the server USED to be named. At 11am today the entries in WINS and DNS got deleted and the path WSS was using to get to the database was gone so it stopped working!

The bad news was that to fix it I had to "UN-Extend" the virtual server, extend it again and then run the Project Server WSS Wizard again. At least it worked!

I thought I had seen some odd issues but this was the more interesting.

Emotional Design of Project Server

Like most people I always thought about the deployment of software as a technical exercise. Then I went to work for Pacific Edge Software in 1998 and I started to understand that deploying project management software was about more than just running setup.exe. I started to understand that it was at least as much art as science. The design of the deployment was less about the software and more about the users and the specific and unique (at least unique in the customer's mind) way they will use the software. My work with Project Server after leaving Pacific Edge has only confirmed this for me.

I recently found a reference to Donald Norman's new book Emotional Design and it puts even more weight behind the idea. In this book Norman examines the psychological attachment that users of products feel for them and how, to a certain extent, this 'feeling' for the product can be part of the design process of the product itself. He breaks total product design down into three parts: Visceral Design, Behavioral Design and Reflective Design. Visceral is the appearance of the product. Does the product look cool? Behavioral is the effectiveness of the product. Does the product actually DO what is expected of it? Then there is Reflective which is the personal satisfaction with the product. Does the product make you feel good. There is certainly more to Normans thoughts on these subjects but the above (grossly inadequate summary) is all you get for free from me. :-)

For sure this book focuses squarely on "real" products. It does mention products like websites but Norman spends much of his time dealing with real 'things', tangible stuff. But this does not mean that the ideas he puts forth in Emotional Design are not applicable in information systems like project management systems. Project Server for example can be broken down into these three areas of design. Some of the factors that fall into these three areas are under our control as consultants. Some of them are in the control of Microsoft.

Visceral Design:
How does it look? Is it visually appealing? When you look at it does it say something?
For the most part this is in the hands of Microsoft. Unless you want to go build your own UI for Project Web Access you get to use the one Microsoft gave us. For the most part the UI is pretty good. It has some things I would change for sure but all in all it's visual impact is a good one. Now there are things about the visual impact of the product that we as deployment consultants can have control over: The Portfolio Analyzer. These views don't come preconfigured. It is up to us to build those views. I have seen some very, very nice looking charts in the Portfolio Analyzer. I have also seen some that sent a shudder down my spine. Even if these views, after getting over their look, put forth good info it will hardly matter. As Norman discusses in his book. People don't like ugly things.

Behavioral Design:
This is the meat. Does Project Server (or Product X) do what the user is expecting it to do? Here Microsoft holds many of the cards but not nearly as many as with the Visceral stuff. Microsoft wrote the code so much of what the product does is really up to that code. However, there is much in this area that depends on our skill as consultants and really as designers. The RBS and the Group and Category security design is all up to us. If we listen to the customer and design an RBS and security deployment that is sound then the user will be happy. If we do not it will not matter how well Microsoft's works the customer will not like the product because the users will not be able to see and work with the right data!

Reflective Design:
This is the part that I still have not wrapped my head around yet. Reflective design deals with how the product makes the user feel about themselves. This is something a little more complex than just designing nice Portfolio Analyzer views or building a good RBS structure. This is about how the product affects the way the user sees themselves for having used the product. My jury is still out on how we as consultants can deal with this aspect of design.

The long and the short is that it may be well worth your time to check out Norman's book. It may just make you a better consultant.

Don't Wait for approval: Projects belong in Project Server WAY, WAY before that!

Most companies I know of that have fairly well defined project management practices in place have a distinct point in time (in the life of a project) where it officially becomes a project. Prior to this point in time the "project" is called a proposal or some other term. When this magical point in time arrives it is entered into a database and a schedule is created as is, generally, a set of documents (charter, SOW, etc, etc). Generally, this point in time falls somewhere just after the "project" has been approved by the PMO or the Project Selection Board or the . So really, when you think about it, it was a Project the whole time. What happens at that magical point in time is that it becomes an APPROVED project. But where was the data about this pre-approved project during the time it was being evaluated by the approving body? Where where these people, and the people that were proposing the project to them keeping and accessing this information? We will come back to this question later...

Now one of the big selling points of Project Server, and really of any project management system these days is that it keeps all your project related data in one place so that it is easy to get to and easy to control access to. All the right people can get to all the right data and once they get it they can do all the right things (and only the things you think are right for them to do). People install systems like Project Server in part so that all their project related data is in one place. But wait! Not ALL their project related data. Remember that most companies only put Approved Projects in their project management system So really what you have in Project Server usually is all your Approved Project related data.

Why wait?

So back for a moment to the project approval board. They get into their meeting and get presented with lots of data about cool new projects in waiting by several PMs. These PMs bring in Excel spreadsheets, Word docs and don't forget PowerPoint decks. These artifacts have likely been passed around a bit before the meeting. Comments have been made, emails sent, versions created. Where are they being stored again? File shares, email inboxes and C Drives.

Why should a project have to be approved before it gets into the system you spent good money on to store your project related data? Put it in there as soon as a PM even thinks it MIGHT be a good idea. Remember, that a project does not have to have any tasks or resources assigned to it to be saved and published into Project Server. It can be a blank shell of a project with a few fields filled in at the Project Level. You can have some Enterprise Project Outline Codes that capture information about the project. These can include, of course if the project is Approved or Proposed, which area of the business the project would serve and even things like expected ROI. You can construct Enterprise Project Custom fields to capture things like expected start date, expected cost, expected work, etc. Capture these things in the Enterprise Project fields and then publish the otherwise blank project. Now you have some high level (Top Down) information about your project stored in your Project Management system. It is saved with an Outline Code value of Proposed. This can then drive some special views in Project Web Access that shows only Proposed Projects. This would be where your PMO and Project Approval Board would live. The proposing PMs could then store the supporting documentation in Windows SharePoint Services where they could be version controlled and easily accessible to the approvers of projects.

If the project is approved it's code field for 'State' (or whatever you decide to call it) is changed to Approved. This makes it visible to a different set of people and the PMs can move on with creating things like detailed task plans and other thins that put meat on the bones of the project. If it is NOT approved it gets marked as "Rejected" or something like that and it is visible in a "boneyard" view where it can be resurrected at a later time.

This is nothing very revolutionary really. It is just a matter of changing the location of the arbitrary threshold across which projects must cross to enter the Project Server system. Think about it. You paid good money for Project Server. Why let things that ARE projects sit outside the system where they can get lost or over looked when there is a perfectly good database just waiting for them!. It is all about Top Down planning really: getting information about projects into the hands of people that need it as early as possible even if it means not having ALL the details worked out yet. The details will come in time but even the sketchy stuff you have at the very beginning can add huge value if people know about it and can get to it in time.

Risk Management is NOT an EVENT it is an ONGOING process!

I'd like to say that the mistaken idea that Risk Management is something that happens once, just before a project starts is an outcome of the recent explosion in the use of PM methods to manage work among organizations that never before thought of their work as projects. But I can't. This is an old, bad idea not a new one. :-)

There are lots of experienced project managers out there that do a great job of collecting potential risks from team members and then rank them and develop contingency plans and mitigation plans for the ones that seem the most likely to occur. But then Risk Management for them is done. It is something they do once and then it is time to move on with the Project Management.

This has a fundamental and seemingly obvious problem: new risks can crop up out of unexpected circumstances. A project can take a turn based on a problem or mid-stream scope change. Risks for late stages of a project can seem pretty distant and unlikely at the beginning of the process but after the project is underway and the new phase is coming up there can be a host of these 'late risks' that can start to seem pretty big on the horizon. But that is only if you are looking for them. If risk management and the contingency and mitigation planning that comes with it is done only once then the eyes of the project are closed (or at least not wide open) to these lingering risks.

Risk Management in all it's glory (collection, analysis, ranking, planning, etc) is something that should certainly happen before the project starts. It can be a strong part of the go/no-go decision that starts the project. However, it should also be part of a process that happens just prior to the start of each phase of the project if not a part of the weekly status meetings that occur in most project organizations. It is also something that is not the sole domain of the PM or the PMO. EVERYONE on the team should be in a risk management mode from the very start of the project right up to dreaded 'lessons learned' meeting after the project ends. They should be keeping their eyes open for things that might go wrong. Even if they seem remote: put them on the list!

Risk Management is not an event. It is a continuous process that should involve the whole team.

Obviously this is not new information. "Old School" project managers (those that were PMs before it became sexy a few years ago) have been saying this for years. Hell even the SEI wrote a huge guidebook on the subject called (aptly) Continuous Risk Management Guidebook that goes into great detail about the idea that Risk Management is NOT an event. While this book is focused on software dev the principles it talks about are applicable on any project, in any environment.

Finding Common Ground or (better yet) Creating New Ground that is Common

Yet another cool article from Boxes and Arrows

In this article, Paradigm Dissonance: A Significant Factor in Design and Business Problems the authors cover ground that is familiar to most in the consulting business: dealing with customers that have very different ways of thinking about and talking about their business or their problems. The article does an excellent job of defining the issue and goes about covering the three basic approaches to overcoming the communication issues: Bridging between the two paradigms (what the article calls an operational approach), Building understanding between paradigms (the Tactical Approach) and then finally the creation of new, shared paradigms (the Strategic approach).

This is one of those very cool articles that covers ground you kind of already know and immediately understand but had never really put the time into to fully define and articulate. It sheds light on things that you had kind of taken for granted. Dealing with Project Server and PM deployments draws directly on the concepts covered in this article. The installation of PM software of any kind is generally a time of huge process and sometimes organizational change. Conflicting paradigms are flying all around you! This article clearly defines a problem that often goes undefined in the world of "this is MINE and THAT is yours".

Well worth the time!

Designing for Limited Resources: Lessons from Information Architecture

I was reading some other newsfeeds and found Boxes and Arrows, an Information Architecture site. IA deals with the presentation of information and the design of things like website usability. One of the articles on the site is Boxes and Arrows: Designing for Limited Resources. It deals with information design processes in organizations where there are limiting factors on the project.

Reading through this it seemed to have some strong parallels to the way that Project Server deployment consultants have to work within an organizational context to design a deployment that will work with existing process or technical limitations. While this article is obviously focused on things like website design I think it is valuable to read design thoughts from other disciplines in order to get a better understanding of how we work within our discipline. Check it out and while you are there check out the rest of the site. There are some very powerful articles there.

The Tao of Project or Who's Driving your Bus Part .5

After writing the Who's Driving Your Bus post last week I remembered that I wrote a somewhat similar thing a few years back for the MPUG newsletter. I dug it up and thought it was worth sharing.

I knew I had used that hammer analogy before!
_________________________________________

"Scheduling engines are not bad, but how they are viewed by the inexperienced project manager is simply a case of mistaken identity. An accountant rarely mistakes Excel as the engine responsible for balanced books while inexperienced project managers often perceive their chosen scheduling tool as the engine responsible for a correct schedule. In both cases, that of a correct balance sheet and a correct schedule, the responsible engine is the human brain."
– Unknown

I saw this somewhere in April of 2001. I don’t remember where, but I kept it because I thought it was the perfect commentary on how many people use and view Microsoft Project. So many users of Project feel that the tool is what gets them a good schedule or even worse, they think it is what gets them a successful project! However, the fact is they mistake a good schedule for “project management,” and then they mistake a good tool for a good schedule. They enter their schedule information into MS Project and then rely on the tool to solely manage their schedule. I think lots of us do this to a certain extent, some more than others perhaps, but it is a VERY common thing.

When many of us look at data on a page, we call it a schedule. But the data exists within a context, which is all of the other things outside of Microsoft Project that affect our dates and durations and work values. The schedule is what we build based on our knowledge of all those “other things.” We need to take these other issues into consideration when building a schedule, and then we use Project as a tool to build a relevant schedule. The analogy we can use is hammering a nail into a wall. A nail is not driven into a wall crooked just because of a bad hammer. Sure some hammers may be better than others, but nails are driven straight or crooked by people. So in the end, it is the person swinging the hammer that makes the difference. So it is with projects.

Project Management is the art/science of bringing in projects within specified parameters of success. One of the many tools we use to aid us in this science is the schedule. MS Project is one of the tools available to us to create and manage that schedule, but it is not the essence of managing the project. Don’t get me wrong—I love Project—I use it everyday and I help other people to use it everyday. Whilst it is a very good tool for building and managing schedules, and the resource usage for your projects is better than any others I have used, we cannot overstate its role in the success of a project. It must be used within the larger context of your schedule, your project and your organization.

Project is not the wood, nor is it the nail. It is the hammer. Swing it well, using the knowledge you have, and you will have a good schedule.

Comments, Please: How to you tell them…?

As PM process consultants how do you handle a client that has a nomenclature established that uses totally non-standard terms for their process elements. Im not talking just about them calling their Microsoft Project schedules “Plans”. Im talking about when you have things like a “Project Selection Board” that does not select projects but rather just prioritizes the projects. What about when you have a client that feels they are at a “CMM” level 3 or 4 but they are really barely a 2? How about the client that has a PMO that they feel is top of the line but what they really do is just facilitate meetings and rubber stamp resource timesheets?

Do you chalk it up to “every company has their own style” or do you tell them what needs to be said and risk alienating a client? Do PM Consultants have an obligation to the greater good of PM to make sure that companies that are going down the path of PM are doing it in a way that at least lines up a little with the other companies around? What if a PM from a company like this goes somewhere else and tries to work? Will their skills and abilities be up to par? Is it the duty of consultants to do their best to try and minimize the number of potential differences?

I have not yet had to deal with these kinds of issues. The side of the consulting work I end up on is much more cut and dried: You can either install the software like THIS or you can install it like that and it will not work! Not a huge amount of room for opinion on my side of the house. But how do the ‘soft skill’ consultants do it? How do you deal with things like this? Or do you?

I think this is the kind of thing that consultants of every kind have to deal with but business process and project management consultants likely face it more frequently than tech consultants.

Please comment on this by using the Comments link below.