By: Jeremy Kadlec | Updated: 2011-10-02 | Comments (10) | Related: More > Professional Development Management
Problem
When most DBAs and Developers hear the term 'project management', I am sure this is not a term that makes them jump for joy. Those emotions are probably from past experiences where they have had issues. To me "past performance does not always dictate future results" when it comes to a SQL Server DBA\Developer who wants to make a difference in their organization. DBAs\Developers are in a unique position in the IT department and overall organization because in many circumstances they work with Network Admins, SAN Admins, Reporting Groups, users, etc., which is not always the case with other groups in the organization. As a DBA\Developer you can consider yourself the hub that connects many spokes in the organization. As such, as DBAs\Developers we have the ability work from the bottom up to make changes which can have a ripple affect across the organization. You make ask how is that possible, I am totally overwhelmed and I need to keep the boat afloat, but I want to be working on the latest and greatest technologies.
Solution
To me the answer is not simple and will not change over night, but you can make ripple affects through the organization by implementing some simple project management techniques. As a first step, you should start to better manage yourself, then figure out ways start to manage your projects in a more accurate and efficient manner. It will not be quick or easy, but the investment should reap numerous benefits for you, your team and your organization.
Let's start to look at some project management tips and techniques to figure out some simple steps to benefit from project management as a DBA\Developer and get these techniques implemented at your organization.
- Expectations - The first set of expectations that you need to set are with yourself. You need to figure out what your goals are as a project manager and how you are going to implement them. Then can you work with your team to set expectations on the project.
- Buy-in - As you make changes, you need to have buy-in from your management and team members. Let them know what you are trying to do, why you are trying to do it and how you plan on implementing it. If your management is interested in empowering you, this will give you a great opportunity to improve your technical opportunities.
- Balance - The reality is that most of us that are DBAs\Developers and chose that profession for a reason. So do not abandon your career or the technical aspects of your career that you really enjoy. View project management as an opportunity to take on more of those areas that you enjoy as opposed to being bogged down with more of a hassle and less technical opportunity.
- Listen - Huh? What? I do not remember that. Does this sound familiar? If so, make sure you make a conscious decision to listen to your team members and take action on the items. You really can learn a lot by listening, but at times people are too focused on proving their own point to be patient and work as a team. Once again, this is a good expectation to set with yourself and the team.
- Building the team - To me your team is your most valuable asset, because with a strong team you can build the processes and technologies needed to succeed. So take the time to get to know folks across the organization. Just don't complete the tickets and move on, but take few minutes every opportunity you get to build a personal-professional relationship with your Developers, Network Admins, etc.
- Process - A big part project management that us technology focused people overlook is process. As a project manager you will learn this reality, hopefully the easy way. One process that we follow for the overall project and each task in the project is the following five step process:
- Define
- Organize
- Document
- Communicate
- Manage
- Project plan - A project plan to me can start off as a very simple tool or can be used for complex planning and financial calculations. In addition, a project plan can be pages of tasks or a simple plan with all of the details in the supplementary documents (server build checklists, upgrade checklists, requirements checklists, etc.).
- Templates - A large sigh is normally heard from most technical folks when documentation is brought up. Everyone knows they need it, but no one likes writing it. Not sure if they know where to start or what to include, so consider building templates to prevent "blank slate" syndrome. Further, to me documentation should really be in the form of checklists and something that has the details, but not in the size of an unabridged dictionary. In addition, with a checklist it is typically easier to figure out if you have met the requirements or completed the process correctly. Here are some recommended templates to consider for your projects:
- Project Plan
- Issues List
- Meeting Agenda and Minutes
- Project Scope
- Roles and Responsibilities
- Communication Plan
- Requirements Checklist
- Design and Development Strategy
- Testing Plan and Testing Exceptions
- Implementation Checklist
- Lessons Learned
- Meetings - I am not sure if the general consensus among IT folks is that documentation is worse than meetings or vice versa. So make the meetings short, sweet and to the point. Make sure you are prepared and set the expectation that your team should be prepared for the meeting.
- Workload - Hopefully by taking these steps you will have a good understanding of your availability and what you really have the bandwidth to take on. The other side of the coin is let people know that you cannot take on additional work and let them know the date you can start working on that new project.
Next Steps
- Think about everything that you have on your plate and start to figure out how to better manage your time.
- Start to think about how you can better manage your projects and think about some of the historical problems you have faced on projects. Depending on the organization and how things are done, it is not a good idea to be a bull in the china shop, but rather start off small, prove the value in the changes and then think about other areas that can be improved.
- If you are in a support role and do not consider yourself to be working on projects per se, take a step back and see if you could get some projects in place that would minimize the support needed. This could give you the opportunity to do new and different things. I am willing to bet you see many of the same problems over and over again, so some small projects may reduce support needs and free up your time to try your hand at some new technologies.
- Do not leave your management out of the loop. As you begin to think about how you can better manage your time and your projects, let them know you are going to try some new and different things. Let them know how things are working and see if they are generating benefits. It might take some time, but they will come. In addition, do not get discouraged if your first time at project management is not perfect. Change takes time and the first time you do anything takes the longest, so you will see the economies of scale then learn your way over time.
- Do not be surprised by resistance changing how you manage yourself and your projects. Some people will not be open to the change and the reality is that you cannot make everyone happy. If you see value and are able to take on bigger and better things, you will be seen as a leader and perhaps asked to address needs others are not asked to address.
About the author
Jeremy Kadlec is a Co-Founder, Editor and Author at MSSQLTips.com with more than 300 contributions. He is also the CTO @ Edgewood Solutions and a six-time SQL Server MVP. Jeremy brings 20+ years of SQL Server DBA and Developer experience to the community after earning a bachelor's degree from SSU and master's from UMBC.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
Article Last Updated: 2011-10-02
