If any of the readers of this have had the fortune (or curse) of working with me on any of my projects, you will already know this. But I am a HUGE proponent of KISS (Keep It Simple Stupid) methodology for designing Software (but can really be extrapolated to most areas of your life).
Early on in my career as a developer, I would strive to create "Art" in my code base. Trying to get the largest functionality, obscurity and "cool factor" from the absolute minimum number of lines. Often, this would require hours of rewriting, tweaking and research to squeeze out a few less characters in a statement. Once I was satisfied with my creation, I would sit back and glow in my own greatness - even if nobody else would ever notice or even care.
But then strange things started happening - any time something needed to be changed or heaven forbid there was an error in my code, nobody else seemed to know how to fix it. Team members would not understand the singular line of code that accomplished all 20 requirements for the function! Nobody else wanted to spend the time to research to figure out the obscure, deprecated function that was used. Slowly, the dim bulb over my head began to illuminate brighter. By creating the coolest thing ever, I had really inadvertently created more work for me. Hmmm... I began to reconsider all my efforts - did I really want to be the one always paged at 9 PM on Friday because the one line of code I produced was wrong and I was the only one who knew how to fix it. I did not.
At that point I began my journey back down the hill - back down to the perceived "common folk", which I now realize is really where I belong to begin with. After many years in consulting, one of the biggest tasks we have in creating solutions for our clients is to not only provide them with a application that works and performs all the necessary tasks, but to also provide them with something that they can understand and build upon themselves. Now, don't get me wrong, KISS does not give us the leeway to not do things correctly - just don't over complicate things needlessly.
I was recently reading a blog about a "Duct Tape Programmer" (read it) which really struck a cord with me. While I don't quite advocate slapping together a solution and calling it a day, there are many truths in this blog that we can all learn from. One of the biggest "features" of our projects is that it must be DELIVERED. Without delivery, it is all for naught.
Now, where did I put that tape?
Showing posts with label project management. Show all posts
Showing posts with label project management. Show all posts
Tuesday, October 6, 2009
Sunday, September 6, 2009
Transitioning Yourself out of an Ongoing Project
We have all been on projects where team members have transitioned in and out during the life of the project, ramping up for a critical development cycle and then subsequently trimming down once that is complete. We all know the basics about what needs to be done when one of the developers or testers are rolling off the project. But what do you do when it is the Project Manager or Project Lead that is to roll off?
During the life of my current (soon to be former) project, I have had the role of Architect and Project Manager for a large application modernization effort - the client has a very large, home-grown application that is the core of their business. Unfortunately, it is hosted on a platform and technology that has been deemed no longer a viable solution due to upgrade paths and licensing fees. For the first two years my team has implemented the core architecture and development pattern for the client to move the entire application into a true N-Tiered, Microsoft .NET, SQL Server environment.
In addition to developing the architecture and teaching the client the correct way to do software, I was also involved in helping the client find talented developers and architects to be our corporate counterparts. These counterparts have now demonstrated to their management they have enough prowess and business knowledge that my role is now deemed obsolute as an architect - one of the downsides of doing our jobs too well, training our replacements so well that they actually do replace us.
During the life of my current (soon to be former) project, I have had the role of Architect and Project Manager for a large application modernization effort - the client has a very large, home-grown application that is the core of their business. Unfortunately, it is hosted on a platform and technology that has been deemed no longer a viable solution due to upgrade paths and licensing fees. For the first two years my team has implemented the core architecture and development pattern for the client to move the entire application into a true N-Tiered, Microsoft .NET, SQL Server environment.
In addition to developing the architecture and teaching the client the correct way to do software, I was also involved in helping the client find talented developers and architects to be our corporate counterparts. These counterparts have now demonstrated to their management they have enough prowess and business knowledge that my role is now deemed obsolute as an architect - one of the downsides of doing our jobs too well, training our replacements so well that they actually do replace us.
So what are you supposed to do when you, the Lead or Manager is the one being rolled off? In this case, the project team is becoming even more of a staff augmentation delivery arm of the client - with the client performing all the architectural decisions and management. You, as project manager, have different responsibilities to the client as well as your team - which sometimes conflict.
For your client
- Determine the rigor that the ongoing project reporting and tracking should take on now that the management control is transitioned. Do we do status reports the same way? Who is on the distribution list?
- Determine the client personnel who will be taking on your tasks? Do they know what all the tasks are that you perform on a day to day or week to week basis?
- Determine how the client should communicate to your team and resolve issues.
For your team
- Determine the chain of command. Who does your team report to? Who assigns tasks and resolves issues?
- Determine how issues get raised back to your management team when necessary.
- Should your team still supply some sort of project reporting back to managemet? If so, what is the rigor and method?
There are a lot of other house keeping tasks that should be taken care of - almost as if the project is just getting kicked off - determining all the logistics of the project administration and day to day dealings now that the point of contact is no longer involved.
Friday, August 21, 2009
Boiling the IT Frog
Here is an excerpt from the book “Boiling the IT Frog” by Harwell Thrasher.
“IT people are very focused on the how, not on the what. The most common mistakes they’ll make are errors caused by doing the wrong things, not by doing things wrong.
Tell IT people what you want to do and you can almost see the gears turning in their heads as they evaluate alternative approaches and eventually come up with various options on how to accomplish your goals. IT people are so focused on the how, in fact, that the most common mistakes they’ll make are errors caused by doing the wrong things, not by doing things wrong. That’s why an IT strategy is so important to a business; it’s the only way to be sure that your IT organization is headed in the right direction.
Some of the worst difficulties in communicating with an IT organization are caused by differing definitions of nontechnical words. For example, IT people frequently use the word project to mean the software development part of a larger Project that includes everything necessary for the business deliverable: design, building, testing, documentation, training, implementation and infrastructure additions. Thus the completion date for a project may be viewed by IT as the completion of the software work. If you don’t clarify the deliverable, then there will be a huge misunderstanding.
Similarly, an IT organization might commit to have some work done by the third quarter. The IT customer will assume this means July 1, but the IT organization will assume it means Sept. 30 at midnight. “
Some other aspects to the book refer to the idea of boiling a frog: meaning, if you place a frog in a pot of boiling water he will jump out immediately. But, if you place a frog into a pot of cool water and gradually heat the water to boiling, the frog will not recognize that the water is hot and will eventually be cooked. This is a good paradigm that we, as IT groups, should be aware of. Sometimes we get so involved in the depths of our project work (developing, debugging, data conversion etc) that we do not recognize that the project as a whole is in serious trouble – we fail to recognize the world around us and perhaps the pressure points have changed. We all should get in the practice of periodically taking a step back (or out) from our daily tasks and routines and truly analyze our projects.
· Has the client’s perception changed?
· Has the client’s business direction changed? From a strategic standpoint, is this project still in line with where they are headed?
· Has the project evolved into something other than what we originally planned? This is usually a good thing, but we should reevaluate to see if it is still heading in the right direction.
· What else is happening in your client’s organization? Are there any new efforts popping up that are in competition with your project? Or maybe an effort has started where we can identity new integration points to expand your project.
The point is, if you don’t stop and take time to evaluate your surroundings from time to time, you (and your project and project team) may end up in boiling water.
“IT people are very focused on the how, not on the what. The most common mistakes they’ll make are errors caused by doing the wrong things, not by doing things wrong.
Tell IT people what you want to do and you can almost see the gears turning in their heads as they evaluate alternative approaches and eventually come up with various options on how to accomplish your goals. IT people are so focused on the how, in fact, that the most common mistakes they’ll make are errors caused by doing the wrong things, not by doing things wrong. That’s why an IT strategy is so important to a business; it’s the only way to be sure that your IT organization is headed in the right direction.
Some of the worst difficulties in communicating with an IT organization are caused by differing definitions of nontechnical words. For example, IT people frequently use the word project to mean the software development part of a larger Project that includes everything necessary for the business deliverable: design, building, testing, documentation, training, implementation and infrastructure additions. Thus the completion date for a project may be viewed by IT as the completion of the software work. If you don’t clarify the deliverable, then there will be a huge misunderstanding.
Similarly, an IT organization might commit to have some work done by the third quarter. The IT customer will assume this means July 1, but the IT organization will assume it means Sept. 30 at midnight. “
Some other aspects to the book refer to the idea of boiling a frog: meaning, if you place a frog in a pot of boiling water he will jump out immediately. But, if you place a frog into a pot of cool water and gradually heat the water to boiling, the frog will not recognize that the water is hot and will eventually be cooked. This is a good paradigm that we, as IT groups, should be aware of. Sometimes we get so involved in the depths of our project work (developing, debugging, data conversion etc) that we do not recognize that the project as a whole is in serious trouble – we fail to recognize the world around us and perhaps the pressure points have changed. We all should get in the practice of periodically taking a step back (or out) from our daily tasks and routines and truly analyze our projects.
· Has the client’s perception changed?
· Has the client’s business direction changed? From a strategic standpoint, is this project still in line with where they are headed?
· Has the project evolved into something other than what we originally planned? This is usually a good thing, but we should reevaluate to see if it is still heading in the right direction.
· What else is happening in your client’s organization? Are there any new efforts popping up that are in competition with your project? Or maybe an effort has started where we can identity new integration points to expand your project.
The point is, if you don’t stop and take time to evaluate your surroundings from time to time, you (and your project and project team) may end up in boiling water.
Keep Your Team On Track with Standups
Are you having a hard time keeping your team members focused and on track? Or maybe you have a team member who gets lost in the weeds for extended periods of time. Or maybe your team does not communicate enough with one another. One technique that I have borrowed from the Agile world is the use of the Standup Meeting.
The standup meeting is a very useful tool to help you – the project lead – keep team members on task as well as get the team in the habit of keeping each other in the loop without spending hours every week in endless, agonizing status meetings.
Standup meetings provide a simple means for team members to keep each other up to date without spending a lot of time in meetings or having to write and read piles of status reports. They focus on quick discussion of progress, plans and problems. This allows team members to get timely updates about others’ progress while you – the project lead (or manager) – quickly determines their tasks for the day by virtue of the team’s obstacles.
There are two key aspects to the Standup Meeting that will make it a powerful tool. The first is in the name of itself – “standup”. Standing encourages concise discussion of progress, plans and problems. When sitting, people get too comfortable and will expand unnecessarily on some points of the update. Standing promotes the feeling of urgency – of a quick hallway conversation and the team will focus on the really critical bits. This is important because if the meetings are short, concise and informative, the team will see value in them and not try to avoid the meeting. A general guideline is to keep the meeting limited to 10 or 15 minutes.
The second key aspect is a little more subtle and will start the team down the path of richer collaboration: encouraging team members to provide updates to each other, not just to the project manager. By doing this, the team starts to see the Standup Meeting as a tool for coordinating their work and keeping up to speed with what others are doing, rather than a necessary evil endured only to silence the constant "are you done yet?" questions.
The standup meeting is a very useful tool to help you – the project lead – keep team members on task as well as get the team in the habit of keeping each other in the loop without spending hours every week in endless, agonizing status meetings.
Standup meetings provide a simple means for team members to keep each other up to date without spending a lot of time in meetings or having to write and read piles of status reports. They focus on quick discussion of progress, plans and problems. This allows team members to get timely updates about others’ progress while you – the project lead (or manager) – quickly determines their tasks for the day by virtue of the team’s obstacles.
There are two key aspects to the Standup Meeting that will make it a powerful tool. The first is in the name of itself – “standup”. Standing encourages concise discussion of progress, plans and problems. When sitting, people get too comfortable and will expand unnecessarily on some points of the update. Standing promotes the feeling of urgency – of a quick hallway conversation and the team will focus on the really critical bits. This is important because if the meetings are short, concise and informative, the team will see value in them and not try to avoid the meeting. A general guideline is to keep the meeting limited to 10 or 15 minutes.
The second key aspect is a little more subtle and will start the team down the path of richer collaboration: encouraging team members to provide updates to each other, not just to the project manager. By doing this, the team starts to see the Standup Meeting as a tool for coordinating their work and keeping up to speed with what others are doing, rather than a necessary evil endured only to silence the constant "are you done yet?" questions.
Subscribe to:
Posts (Atom)