Project Management

Following the footsteps of people bigger than me, like Mike Elgen and Dries Buytaert, I've decided to focus this year on my personal blog and spend less time on my other websites and social media networks. This has been a long time coming but probably the straw that broke the camel's back was Google's decision to shutdown my favorite social network, Google+. 

Earlier this year, I started a new blog in hopes of me getting back to dedicating more time for my writing. The goal was to write one article a week as I had finally broken free of my burnout from blogging. In the first few months of the blog, I wrote about half a dozen posts but by Spring new articles were no longer being published at Fifty-Two Posts a Year. I once again found the demands of work, family, outdoor hobbies, and managing my other websites were of higher importance. So, time marched on and I now find myself with one more website that started with good intentions but now resembles a ghost town with too few visitors and too little new content.

Most people regret wrong turns. When my son was 20 months old we visited his grandparents in Kansas City. He was a great little traveler on the way there but on the way back he hit his limit to being "uncomfortable" in the back seat. When we saw a train on the tracks east of the Interstate, I decided to take the next turnoff in hopes the train would distract him for a few minutes. Unfortunately, once committed to the new highway there was no way to turn around for 18 miles. My 5 minute pause delay turned into a much longer detour. Worse, we failed to grab our prize as the train was long gone from our view. Eventually, I yielded to our fate and made another turn for the country roads. 

CMS Watch has a very good article on their site titled, "Question CMS Consolidation". The article serves as a reminder for IT and managers that, although technically feasible, an organization may not want to put everyone on the same content management system (CMS).  Why would an organization want to to consolidate their systems in the first place?  For those at top of the organization there may be some obvious reasons to unify the organization onto a single CMS.

Many organizations are looking at a portfolio of dozens of content management systems running somewhere on their network. From sheer tidiness alone, it’d be nice to have a shorter list. And such tidiness can have real benefits: better negotiating leverage with vendors, reduced overhead to manage contracts, reductions in the number of servers and hence in datacenter space (with attendant power and operational costs), and so on. Finally, increased demands for compliance and control are placing a premium on simplifying information management.

In my own organization, we have had both Internet and intranet servers since the mid 1990's supporting operations and administrators.  While we moved our Internet web servers onto a CMS a few years ago, it is only the past few months that many of our offices and departments have shifted their intranet from static pages to much more dynamic system.  As many of our field offices migrate their servers to utilizing newer Web 2.0 and collaboration applications, IT and management have a strong desire to consolidate those applications and servers.

On Planet Drupal, there have been a number of posts lately about the difficulty project leaders and developers have in  saying "no" while working on a project.  As much as Project leaders want to please both their client and their team members, real leaders understand the responsibilities they have in saying "no".  More specifically, I'm talking about Boris Mann's post, "Susan Mernit on the role of "no" in product development" as well as Laura Scott's own post You've got to know when to 'no' them .

This is all interesting to me because for some time I've wanted to talk about Aaron Mentele's post, Every once in a while you need to fire a client.  Aaron Mentele is a web designer and co-owns a web design company based in Sioux Falls, SD.

There comes a time when most project leaders have mastered the the ability to say "no" to certain requests.  But what happens if you find yourself not really saying "yes" to the client?  Do you have it in yourself to recognize that by having to answer "no" so often in a project you likely shouldn't have taken on the project in the first place?  What are you to do?