Some of the feedback I received from the first part of this series suggested that complex projects require project management software. I tried to explain why I disagree, but I can’t keep myself below my self-imposed limit of 800 words. Suffice it to say, I think project management software is great if your goal is to manage resources, report status and control budget on a large project that will proceed pretty much according to plan. When the project is smaller, or when the project team is talented and agile and the project plan can change in response to new ideas, project management software gets in the way.
I’ve been managing projects, large and small for over 30 years, and long before “agile” became a buzzword, that was the kind of project I often found myself managing. The key to successful agile projects is to have good and passionate people on your team and to facilitate communication between those people. SharePoint is an ideal platform for managing these projects. Let’s explore a few important requirements of these projects and consider how SharePoint satisfies those requirements:
Everybody Knows Where We’re Going – Each person, regardless
of their role in the project, needs to know what the project goal is. If we have an understanding of the master plan, we can adjust our individual tasks to better satisfy the objectives. The SharePoint site we are using as the home base for our systems development project has this kind of information. There are document libraries which hold the rigid procedures and algorithms that describe the system. There’s a library of Excel models which test the implementation of those procedures and algorithms. There’s a list of SQL statements which extract the data from our production database to supply those models. Every document and model is described and every change is described through Version Comments. We’re also using a wiki to design new and modified processes and screens. The wiki is great for this because we can store an image of the screen and functional description and users can explain what does and doesn’t work. Then we can adapt.
Nothing Important is Lost – An agile team makes changes as they work; they see opportunities to save time or to improve operations and they pursue them. At the point of change, the people involved fully understand their decision, but that understanding quickly fades as they move on. We created a Custom List to track our work and we added columns to this list to capture the rationale for changes. Now, in the event that our stroke of genius impacts something down the line, we know what we did and why we did it. What’s great about SharePoint is the ability, as in this case, to modify a list to accommodate new types of information. Parallel to this strength is the ability to create new and different lists. For example, we have a separate Custom List tracking changes we’ve made to database tables. We have a separate list for changes we’ve made to system constants. We have a list where we track implementation progress and test results. This is starting to sound like an iPhone commercial, “yeah, there’s a list for that…” but it’s true and it works.
People Stay Informed and Information Stays in Sync – Not only do people have to know where we are going, they have to know when we’re taking a shortcut and they have to know when we get lost. SharePoint alerts take care of this for us. Establishing alerts removes a communication decision from the team member. No one will ever say “I’m sorry, I didn’t think you would be interested in that…” – if you’re interested, you have already established an alert. Keeping information in sync is difficult when you’re working from documents and lists and spreadsheets but it’s less difficult when they are all stored together. The ability to add columns to document libraries and attach documents to List items add additional ways to keep related items together. Finally, adding to the value of proximity is the ability for these lists to reference each other and, as I’ve talked about earlier, update each other.
of their role in the project, needs to know what the project goal is. If we have an understanding of the master plan, we can adjust our individual tasks to better satisfy the objectives. The SharePoint site we are using as the home base for our systems development project has this kind of information. There are document libraries which hold the rigid procedures and algorithms that describe the system. There’s a library of Excel models which test the implementation of those procedures and algorithms. There’s a list of SQL statements which extract the data from our production database to supply those models. Every document and model is described and every change is described through Version Comments. We’re also using a wiki to design new and modified processes and screens. The wiki is great for this because we can store an image of the screen and functional description and users can explain what does and doesn’t work. Then we can adapt.Nothing Important is Lost – An agile team makes changes as they work; they see opportunities to save time or to improve operations and they pursue them. At the point of change, the people involved fully understand their decision, but that understanding quickly fades as they move on. We created a Custom List to track our work and we added columns to this list to capture the rationale for changes. Now, in the event that our stroke of genius impacts something down the line, we know what we did and why we did it. What’s great about SharePoint is the ability, as in this case, to modify a list to accommodate new types of information. Parallel to this strength is the ability to create new and different lists. For example, we have a separate Custom List tracking changes we’ve made to database tables. We have a separate list for changes we’ve made to system constants. We have a list where we track implementation progress and test results. This is starting to sound like an iPhone commercial, “yeah, there’s a list for that…” but it’s true and it works.
People Stay Informed and Information Stays in Sync – Not only do people have to know where we are going, they have to know when we’re taking a shortcut and they have to know when we get lost. SharePoint alerts take care of this for us. Establishing alerts removes a communication decision from the team member. No one will ever say “I’m sorry, I didn’t think you would be interested in that…” – if you’re interested, you have already established an alert. Keeping information in sync is difficult when you’re working from documents and lists and spreadsheets but it’s less difficult when they are all stored together. The ability to add columns to document libraries and attach documents to List items add additional ways to keep related items together. Finally, adding to the value of proximity is the ability for these lists to reference each other and, as I’ve talked about earlier, update each other.
One thing I’ve learn in 30 years of managing projects is that project success is most dependent on the people involved. The goal of a project manager should be to support those people not simply report on their progress. SharePoint, due to its robust features and agile nature makes it easy to support your team and gather the information necessary for reporting. There are questions though; does SharePoint scale in support of large projects? Can SharePoint accumulate information from multiple related or unrelated projects? Can we transition from “under construction” to “in use” to “planning for maintenance”? I think the answer to all three questions is “Yes” but I would welcome your thoughts. Please add a comment or shoot me an email. If you want to know why I chose the picture above, or if you want to understand some of my inspiration for managing projects the way I do, read Mob Software: The Erotic Life of Code by Richard P. Gabriel & Ron Goldman.
Posts
0 comments:
Post a Comment