Driving home from rugby practice last week I started thinking about something the coach said. It is a phrase that anyone who has played sports has heard. Play “heads up”. Our rugby coach wanted us to keep our heads up to see what was going on around the pitch while we played to look for opportunities and/or threats.

As I thought about this more, I started to reflect on my work projects and the major account that I manage. I realized that much of what I am doing is a result of working with my head up and looking for opportunities to help my client or my company. We gained an additional project for Dynamics when I was on site doing SQL Server work because I was listening to my client talk about their environment and the struggles they were having with their Dynamics implementation.

This concept is not just for managers. Project team members can identify issues and prevent gold plating by being a heads up team member. If a team member knows the scope of the project and is actively watching out for anything that will threaten or change scope, he can help ensure the success of the project.

As project managers, how do we actively manage with a “Heads Up” mentality and how do we encourage our team members to be “Heads Up?

As project managers, we should by definition already be doing this. When we are actively controlling change, quality, and scope. While these process group often allow project managers to take a heads up view of a project we often miss the opportunities when communicating with stakeholders, team members, and clients.

My teams are highly technical and laser focused on the task at hand. I have discussed this topic with some of them. What I have found is that spending time helping them better understand the business goals of the project and the stakeholder requirements can help increased their visibility into the project. A better understanding of the project and not just their specific project activities gives them the information that they need to play head up.

Playing heads up allows us to see opportunities and threats on our projects. I would love to hear how your team manages projects from a heads up prospective.

I have been keeping a eye on the team over at 37Signals for a long time. I have read their Signal vs. Noise blog for quite some time. I also use their products Basecamp and Highrise to manage projects and contacts. The founders, Jason Fried and David Heinemeier Hansson, recently released the book Rework.

I purchased this book around lunch today and couldn’t put it down. I finished it in one afternoon. My main thought: companies that follow the principles in this book are the kind of places I want to work. Rework turns traditional business theory and planning on its head and teaches to filter out the noise, identify the heart of the problems and get things done. Git rid of long, pointless meetings, and what if business plans and start moving.

This won’t be the last time I read Rework. I already have some of the principles posted near monitor at the office. It doesn’t matter if you are a mail clerk or a CEO you need to read this book.

Jen McCown (Blog | Twitter) recently asked some tough questions about documentation in her blog post Documentation. Tag, your it! As a consultant I live and die by documentation. When I come into a engagement and things have been well documented my life is easier. More often than not the converse is true.

Stance on Documentation

Documentation is a necessity and I love it but I also hate it. Not unlike most of my colleagues I have a backlog of work that would keep me busy for the next year. Many times it is much easier to complete the task at hand and move on to the next one without taking the time to provide the documentation for the solution that I just finished.

Documentation and My Team

While I struggle with my personal love/hate relationship with documentation my team does a pretty good job of documenting our environment.

Requirements

There is never enough time to do it correct but there is always time to do it over again -Unknown

Properly documenting and understanding the scope of work for each task is the first rule in project management. Properly doing this helps minimize scope creep and control the quality of the work product. A huge part of project management is managing client expectations and if the requirements are documented, both client and my team know what to expect from each other.

Change Request

Change Request are very important to the stability of an IT environment. Documenting a change request is only one step in a change management policy that needs to be enforced in an environment.

Before implementing change management in our environment it was not uncommon to have unexpected outages during the course of a business day. This was never intentional but the many systems administrators, my self included, would make changes that would step on the actions of other administrators. This would cause unexpected consequences and a service interruption.

Post implementation of documenting change requests saw a drastic decrease in service interruption due to changes during the business day. It actually allowed us to increase service uptime numbers from 99.9 to 99.98 over 6 months.

Data Dictionary

We currently don’t have a Data Dictionary. This is mainly due to the amount of data that we would need to document. I was recently introduced by Jorge Segarra (Blog | Twitter) to a product from Red-Gate called SQLDoc. The product allows for quick and simple documentation of a database. I was smitten.

Shortly there after I was contacted by Bryan Kight (Blog | Twitter) about a product that his company has produced called BI Documenter. The product not only does what Red-Gate’s software does but so much more. Look for more information on this product in a future post.

Microsoft’s Project is a very standard project management tool that most Project Managers are all to familiar with. While Project is a great application it was limited to local information. Microsoft’s Project Server extends Project’s capabilities and allows the sharing of resources and information across an Enterprise.

Project Server 2007 is built around the SharePoint platform and creates four databases upon installation that house project related data. The four databases are Archive, Draft, Published, and Reporting as can be seen in the image.

For any DBA who has tried to deal with SharePoint restores you know the nightmare that can become. Thats a topic for another post entirely. After one such incident and a help ticket with Microsoft it came to light that Project Server has a built in ‘backup’ capability. Microsoft’s words not mine. It is really more akin to version control than backups but that is besides the point.

In the Schedule Backup section of the Server Settings a Project Retention Policy (versions) setting can be found. By default this is set to zero. Microsoft’s best practices are that this be set to a minimum of 3.

Now on to why DBAs supporting Project Server need to know what is going on here. Project server operates by storing data in three of the four Project Server databases. When a project is created and saved to the server but not ‘Publish’ it stores the information in the, you guessed it, Draft database. Once the project has been published it moves to the Published database. I know, you are still with me. When the retention policy is set to 3 the Archive database is used to retain this information. Again not shocking. What needs to be planned for is the space that this will take. Your archive database will be, in this example, 3 times larger than your published database as well as the server activity that will be occurring when the ‘backup’ is taken.

Above is a shot of what gets backed up and when it does. This can be found in below the Project Retention Policy box on the Schedule Backup screen. It was also Best Practices to stagger these times so they didn’t all hit the Project Server queue at once.

While I have enjoyed using Project Server as a Project Manager can sometimes be a pain in the butt as a DBA. Do you have any Project Server stories you would like to share?