If you include the work that I have done in the theatre as a stage manager - I've been engaged in project management since 1989. 24 years is a long time to think about and practice a craft. I wrote a bit about how technical theatre seems to impact software project management. I've been writing about technology and project management since 2004/05 and I've been managing the builds of complex database driven systems since 1999. All of this has led to my using many different project management styles and tool sets.
I've submitted a session in Portland on just this subject.
Learn from my 18 years of Project Management Experience with Technology. I've done it all - cowboy, waterfall, extreme, and agile scrum.
- Waterfall doesn't always work
- Agile has a place, but isn't the holy grail
- Cowboy can kill the relationships you have with your stakeholders
- How "Fixed Scope" is a lie
- That a combination of approaches is the answer
Project management requires a blend of techniques and tools to effectively shepherd projects from ideation to release. We'll explore and discuss different tools and methodologies that can help make your project successful.
When I was at BADCamp a few weeks ago, Addison Berry asked if I'd be willing to participate in a podcast on project management. I am a process geek having spent years working with 100s of developers, product managers, executives, clients, and project managers across the arts, government agencies, non-profits, media companies, schools, sports, and retailers. This has made for so many different configurations of project management styles, methodologies, and personalities. I've learned from all of them.
What will I be talking about? About a year ago I was asked if I would keynote at Drupalcamp Austin on Project Management. I quickly altered a presentation that I was working on - it was intended more as a work-shoppy kind of affair - to be more key-notey and included cats, manholes, fighter jets, pyramids, castles, waterfalls, ravens, monsters, wine, books, and just a little H.P. Lovecraft. The presentation was updated for Drupalcon Denver and then, again, for Drupalcon Munich. Since becoming the CTO at Trellon, I've continued to evolve my thoughts on process as I work closely with this distributed team. I'll be making adjustments to the presentation on Tuesday to reflect some of these shifts.
I've included the previous presentations below if you're curious. Otherwise, come on out to the DBUG meeting on October 23rd - enjoy some hot pizza and cold refreshments provided by Aten Design Group and the amazing space provided by the Open Media Foundation - and we can have a great time together!
We all have pet peeves. We have our "favourite" client or clients that have done things that baffle us. We've all had employers that have been problems or employees that just weren't right. We have funny stories, sad stories, maddening stories about how a project has gone spectacularly wrong. We've had situations that have seemed like they were going to be a complete disaster but then have turned around. We've had disagreements with our colleagues and/or competitors.
At Drupalcamp Austin, I'll be talking about process. I'll speak a bit about tools and strategies. I might share a few scenarios that could make your hair stand straight up. I'll be talking about lessons I've learned across many years of managing projects in Drupal and in my life as a custom software architect and project/product manager.
So, here are 10 things that drive me nuts:
In the previous post, I wrote a bit about the tools I've used in project management. This post is going to focus a bit on process and how one might assemble usage of the tools.
First off, if you work in a development shop - you really should devise a process that works for your team and stick to that process. As Malcolm Gladwell says, you need to practice any "art" whether it is ice hockey, singing, lawyering, etc for many hours to perfect it. Context switching between processes will disrupt your flow state and make it tough to learn efficiencies. That doesn't mean to say you shouldn't have retrospectives at the end of a development cycle to discuss what worked and what didn't work. However, you shouldn't alter your process specifically to please a client - it doesn't work.
If you work for a company where you are making improvements to the site, you should define a process and stick to it to provide predictability to your stakeholders. They want to know what to expect and when.
Relatively recently, at Drupalcamp Colorado, it was suggested that I lead a session on project management and the tools those in our community might use. This seemed like a segue from a series of interesting conversations that were started at Drupalcon Chicago. You see, the general feeling is, there is no silver bullet. There is no grail of a tool that does everything a single Web Producer, Project Manager, Product Manager, or Content Manager might need or want. There is clearly a gap that is filled with a series of different products. This walked hand in hand with a desire to review processes at work and engage in course corrections. It is an excellent habit to follow - look what you are doing with a critical eye, analyse why you are doing it, and make changes as needed. I have worked across four different shops with a wide variety of different ways of practicing project management. I have used these methodologies and tools across ~ 50 different Drupal projects and another 25 or so custom PHP MySQL projects.
Matthew Dorman from NorthPoint gave a presentation at Drupalcamp Colorado on project management, focusing on questions to ask with a look at different tools. These are my notes and the video I took of the session is at the bottom of the post.
Get involved by going to:
- NorthPoint uses Jira with Greenhopper
--allows you to do agile development with scrum, create stories, issues, etc
- uses Open Atrium
- Pivotal Tracker
I started writing about dotProject on the 28th of October. I've set up a small demo project on my localhost to demonstrate how the tool can be used to manage a project.
Any given ticket can have any number of workers assigning time to it. Each of those logs can be assigned a different cost code. That means you can track different charge levels based on the person doing the work on a single ticket.
This evening I continued to experiment with setting up a project and creating tasks using dotProject.
First observation - setting up your first task is rather confusing. The tab is buried deep.
First off, the software allows you to manage all kinds of companies. The tab set includes:
- Not Applicable
Project Management tools are often on my mind. I've used many different tools in development of Web systems from Bugzilla (don't use it for project management, great bug tracker, terrible planning tool), to Drupal Case Tracker, to Rally, to Unfuddle, to JIRA, to MS Project, PHProjekt. Some are open sourced and others are proprietary. They all have the same goal though - to allow you to manage and track projects from conception to deployment.
While some tools have been better than others and yet other tools have been more like trying to drive a square peg through a round hole. For example, using Bugzilla to try and manage a project start to finish proved challenging. PHProjekt lacked the feature set that was needed to effectively manage. Drupal Case Tracker was OK, but had its quirks. JIRA is really cool, but the tools that make it especially attractive are licensed.
I've been told that dotproject has a robust feature set and also includes tools that rival MS Project. So, in this blog post I'm going to run through my experiences setting dotproject up locally. Future posts will discuss the pros and cons of the package. I am a Mac user, so I'm focusing this tutorial in that direction, but the directions should work whether you use MAMP, LAMP, XAMP, or WAMP. If you are wondering what the heck these are, check out the Wikipedia Entry