Managing Projects with a Shrinking Budgets and Limited Resources

I was recently asked, “How do you manage projects in medium sized company with limited resources?”

I thought back to one of my previous positions where I had to fill many hats. I was the CIO on the executive board setting strategic direction for the company, I was the Director of Technology managing a very small IT shop, I was Project Manager for IT Infrastructure projects, application development projects, and a few non-IT related corporate projects (only because I was the only certified PMP in the organization). I also had to function as System Administrator and Help Desk Support on occasion.
Times were tough on all departments. Revenues shrank, budgets shrank, staff shrank (not that the people shrank, but the number of people shrank).

We had to regroup and devised some strategies to accomplish our goals for the IT department and for other corporate projects that were under my direction. There were five areas that had to be addressed quickly.

Get Prioritized. We had to look at each project and how it would benefit the organization. We spent one day reviewing each project to determine the relative value. Some projects needed to continue because it made financial sense. Some projects were to continue because of regulatory requirements. Many projects hit the kill zone or was put on a “spend no more until further notice” status.

One thing I cannot emphasize enough. The review was at the highest level. There were no surprises at the top. The ”top” was part of the review process.

Get Lean. Needless to say if a project was to pass the executive gauntlet, it didn’t necessarily receive a rubber stamp in terms of budget and resources. This was a time to eliminate any waste in the project.  I also used Lean in operations to find and eliminate waste. In a future blog we’ll discuss Value Stream Mapping and how it can open the eyes of the blind to areas of waste in a process.

Get Agile. For the application development projects we embraced Scrum. I was the first Scrum Master (and Product Owner). For IT Infrastructure projects we introduced Kanban. This methodology worked really well in this organization since most of the project team was also the operation team. We were on a hiring freeze as well as mandated to reduce outsourced consultants. We did not have resources to pull staff off of their operations routine, but the IT staff did have chunks of time to work on IT infrastructure projects. We used Kanban along with a well groomed product backlog to determine where the IT staff used those extra chunks of time.

Get Disciplined. According to Critical Chain Project Management thinking, the three greatest time wasters are due to Parkinson’s Law, Student Syndrome, and Bad Multitasking. If you ask me how long it will take to complete a task, I will pad that time and then take every minute of that time to complete it. That’s Parkinson’s Law in action. Student Syndrome is a lot like college, I will blow the task off until the absolute last minute, then cram to get it done on time. Finally, I found Bad Multitasking to be a hard habit to break. I find myself with a list of tasks to work on (A, B, and C). During the day I might start on A, then switch to B when I get bored with A. Then someone comes in and asks where are we with C and I switch to working on that task. Every time I stop and switch, there is cost in time to “switch thinking”. This is especially true with application development.

I will save a more thorough discussion of Parkinson’s Law, Student Syndrome, and Bad Multitasking along with Critical Chain Project Management for future blogs.

Finally, as a Project Manager and a department manager, it was my responsibility to Monitor and Direct, not manage and control, not stifle productivity and efficiency. Knowing I was under the gun to deliver, I had to force myself to bite my tongue on many occasions and NOT micromanage. I kept up to date on status and offered suggestions and guidance. However, I allowed the team leaders to manage their part of the project.

This strategy worked. We produced results. We completed projects that were essential to the success of the business. The most important and by far the one key that made this a success and will put your organization on a successful project management foundation is Management Buy-in. They cannot be passively involved; they have to be directly involved.

Good luck with your project management endeavors.

Why another Agile blog?

As I was thinking about blogging, my mind continued to “wonder” and “wander” about what should my first blog be about. I tend to be a deep thinker in a shallow pool. The more I thought about it, the more complex the answer became. Finally the epiphany emerged. For my first ever blog allow me to talk about me and why I’m doing this.

As the Director of IT in a small company, I made huge strides with the IT infrastructure. I moved from an electrical closet with three servers and was able to build a small data center. I turned up the connectivity from 10 megabit to Gigabit and wired the campus with fiber. I installed secure wireless throughout the campus.  I migrated the servers from Novell/GroupWise to Windows/Exchange.  I was able to accomplish this in a three year timeframe. I was a huge success, a shining star.

The CEO was so confident in my abilities, she charged me with developing a corporate information system that would allow all departments to share client information. I was cocky enough to think I could do this, after all I was a certified PMP .. Project Management Professional.

I began floating down the stream in true waterfall fashion. I spent the first six months gathering information, interviewing key stakeholders. I allowed each department to create their wish list. I wheeled around the “feature cart” to each and every person that might have a want or need.

I designed the system, created flow charts, and data diagrams. I knew exactly what the system was to look like, to feel like, and how it would work from end to end. At least I thought I did. I contracted with a development team to begin hammering out the code, phase by phase.

Six months goes by and of course the team is struggling with the never ending pile of features. Of course during the development more wishes and wants came in and as a good team player, I could not say no.

Nine months after the coding began we had something to demo. We gathered all of the key stakeholders together and unveiled our baby. You can imagine how it went. What I thought was the perfect design was far from perfect in their eyes. It was a flop, not to mention it was over budget. My earlier earned stardom began to fade as the project continued.

I licked my wounds, cowered off to my IT cave, and began to rethink my career. As I was searching for job opportunities in project management, I kept seeing some unfamiliar keywords like Scrum Master, Agile, and Lean. So I went to the best resource known to IT .. Google. I poured through search screen after search screen, reading blogs, reading white papers. I came across a YouTube Video .. Scrum Master in Ten Minutes by @Hamid. It was at that moment I found my passion.

That was on a Friday. I spent that night and the rest of the entire weekend in YouTube looking for more about Scrum. Since that time I have become a Certified Scrum Master as well as achieved the PMI-ACP. Needless to say I have left the ways of waterfall and now help others navigate their way to shore to find their path toward Agile.

In my future blogs I hope to help Agile newbies find answers to similar burning questions I had when I first sought Agile knowledge. I hope to that this blog sight might be that initial spark to someone that creates that burning fire in their quest for understanding. But most of all .. I hope to learn from the Agile Masters who offer advice and direction as I continue with my Agile journey.

For now .. I’ve Gone Agile !