Posts filed under 'Project Management'
One of the common problems we encounter in developing software is that it is difficult to completely know everything about a desired solution before we begin. Another is that sometimes we lose focus on what exactly we’re supposed to be building while another is having a too limited view of the project. Let’s take a look at these common blind spots that can plague a software project and how we can deal with them.
Losing Focus on the Solution
The saying goes, “When you have a hammer, everything looks like a nail.” When you have a programming language, methodology, third party library, or other tool that you enjoy using you can start to focus on the tool rather than the solution. Some developers do this when it comes to OOP, over designing and tweaking objects while the actual application development languishes. Others become consumed with a particular language, tool, or method and apply it blindly, assuming it’s a panacea for any and all situations.
The important thing is to never lose sight of the goal of producing a working application within a given timeframe. If your project is encountering schedule slips related to redesign or if problems or limitations with a particular language, tool, or method are becoming readily apparent, take a step back and evaluate what you’re doing. Do what it takes to get your focus back on developing the solution that is needed, even if it means scrapping a favorite thing.
If you’ve ever seen racing horses, carriage horses or farm horses you’ve probably seen them wearing blinders. These pieces of leather or other opaque material prevent the animal from seeing behind them or, sometimes, to the side as well in order to keep the focused on the task at hand. Sometimes people who are too narrowly focused on a problem are said to have blinders on. In development projects, this can happen when programmers and architects ignore what interactions their application will have with other programs or the business processes of the organization.
This can be a very subtle blind spot to detect because often things will go very smoothly at first since the tight definition makes it hard to wander off the path. Problems begin to crop up when the new program is integrated into the whole software and business framework. For example, your application updates records in a particular table while another longstanding process deletes records out of this table. Or perhaps users find your program a roadblock to performing their jobs because they have to go out of their way to work with it.
To avoid this blind spot don’t allow haste, political pressure, or just pure laziness to limit your analysis and design to a narrowly defined set of criteria. Make sure you allow room for changes, even if it’s in a later release, to handle these unexpected situations. Some development methods make this kind of problem easier to avoid by involving users in the process but you still have to watch out for this blind spot due to its hidden nature that can sneak up on you.
Assuming We Know Everything
What is the scope of your ignorance? What is it that you don’t know and don’t know that you don’t know it? It is often said that in a given software development project of a reasonable size that only about 20-40% of the problem is known while the application is being developed and that known unknowns, the boundary between knowledge and ignorance, only accounts for another 10% or so. This leaves a whopping 50% or more of a blind spot that can come back to give us considerable trouble. So, what can we do about it?
The first thing, of course, is to make sure we, and people associated with the project, understand that we’re not going to know everything about the problem domain. Jim McCarthy of Microsoft refers to this as “lucid ignorance”:
It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this “lucid ignorance,” disaster will surely befall you.
It is better to admit our ignorance and have a successful project, even if it isn’t a 100% success, rather than assuming we know it and have a project failure. Ultimately, our goal has to be to reduce the uncertainty gradually as we classify our ignorance and break it down into manageable pieces. But, we still have to be aware of the fact that we still won’t know everything.
Have you seen any of these three blind spots? Do you have any other examples of blind spots in the software development process? Let me know what you think by leaving a comment.
October 4th, 2007
In my previous article, 10 Ways To Insure Project Failure, I focused on project failures that resulted from management mistakes. Of course, failures can happen not only from poor management but from basic design mistakes, inadequate or improper programming tools and/or coding techniques, bad processes and/or procedures, or external forces. Once you’ve recognized that a project is in trouble, what should you do to help it recover or even determine if it can or should be recovered? Here are some steps you can take to turn things around.
1. Stop Work and Scrap the Current Schedule
When problems are mounting and it is obvious that a project is in trouble, many managers and team leads will continue the death spiral even further. They’ll often do this by forcing extra work and stress on the development team. Or they may take other failure prone tactics like bringing consultants or more programmers, believing a new tool is a panacea for all the problems, or other such things. The answer, however, is to stop the work on the project. If things are going wrong it should be obvious that continuing down the wrong course will only make things worse.
Scrapping the current schedule is another politically risky move. The company may have a lot riding on the work being done by such and such a date. You have to make sure everyone understands that the present schedule was irreversibly flawed and unrealistic. Such a schedule gives false expectations to upper management and users as well as demoralizing the developers. Emphasize that a new, realistic, schedule is the goal of this recovery process.
It does take some political courage to do this. Some organizations will turn on a manager or lead who stops a project cold and speaks the truth about the impending disaster. To sell it politically, emphasize the positive aspects, that it will save money and save the project while just continuing the status quo will result in failure.
2. Review and Reevaluate Everything
Go back to your original requirements and design and see if you can spot the flaws there. Perhaps the requirements are pie-in-sky and need to be cut back to something more realistic for the time frame. Maybe the design was too ambitious and needs to be scaled back or gradually phased in over several iterations.
Take the time to review each feature and rate it according to its importance to the project. Force everything to be rated at least with a ‘must-have’, negotiable, ‘nice to have’, or ‘can wait’. Just don’t let the pointy haired bosses say everything is a top priority.
Look at the programming tools you were using. Maybe that hot third party development framework or control wasn’t so hot after all and should be eliminated or cut back. Maybe making it a 100% web based app isn’t practical given the requirements you have. The objective is to discover if using the wrong tools is holding you back.
Review the code. Perhaps your team is new to OOP and is having trouble with developing classes. Perhaps they’re new to .NET or whatever language you’re using and they’re making coding or design errors. Having the team do review work is also helpful politically since some will complain that the programmers are ‘goofing off’ since the stop work order.
The goal of this part of the process is to identify problem areas so that corrections can be made.
3. Is the Project Feasible?
Now that everything has been reviewed and the causes of the problems should have been identified, it’s time to decide if work should continue or not. This is the moment of truth.
If the problems that have been identified in the previous step indicate that there is no way the project can be completed ‘as-is’ then it should be canceled. For example, if the reevaluation indicates that it will take a year to complete the project with a staff of 5 programmers but the budget only allows for 2 people and the schedule is for 3 months, it should be obvious to all that it won’t work.
It may be feasible to recover a portion of the project and do it within the needed time line. Don’t scrap the whole project but look for things that can be recovered and reused for a more reasonably scaled project.
It could be that one minor situation was causing the delays. For example, bugs in third party library might be the problem. In that case, the project might be put back on course quickly by replacing the offending component.
Now it’s time to negotiate the changes in the schedule and specifications with the project sponsors. This can be difficult if you’re dealing with a politically charged situation but, if the project is to be recovered, it’s a necessary step.
First, examine and review the specifications and requirements with the sponsors. If the flaws were found in this part of the project, work on negotiating on these first.
Next, take a look at the project features with them and tell them what can and can’t be done, what can’t wait and what should wait, and so forth. There will be some disagreement but the objective is to put together a realistic set of features that everyone can live with.
Lastly, negotiate the schedule. Don’t commit to anything firm yet. Explain that you will need to get with the development team to put together a realistic schedule based on the negotiated feature set. You can give a wide estimate but if you commit to a specific date or even a narrow time range you may very well be setting yourself up for a second failure.
5. Prioritize and Estimate the Remaining Tasks
Now that you have what should be a realistic feature set get with the development team and have them develop estimates for each of these features. Keep the granularity small by breaking down tasks into units of no more than a day or two. Any larger and you will risk being right back where you started.
Also make sure that you include estimates on tying up loose ends and stubbing out features to be added in a later release. And, lastly, make sure that you don’t shortchange any testing or documentation that will be needed as well in your estimates.
6. Build a New, Realistic, Schedule
Now that all of the tasks have been identified you can use them to build a realistic and accurate schedule. Once this new schedule is ready, take it back to the project sponsors. If it doesn’t meet with their approval then you’re back to step 4, negotiating. Determine what to drop to get the project to fit the needs and expectations of the sponsors while making sure that you keep it within the task estimates you’ve developed. The goal is to construct an accurate schedule that everyone can live with and that can achieve the desired outcome.
7. Get Back To Work
Now that the project is back on course, it’s time to begin work again. Make sure that you don’t repeat past mistakes. Beware of bad development habits creeping back in or project sponsors trying to use political muscle to get a dropped feature added back in. Keep a watchful eye out for existing problems recurring or for new ones cropping up. Remember that slips and problems usually happen very slowly and gradually so don’t let them grow by ignoring. Make sure that the feature ‘micro-stones’ are being met. If one isn’t quickly deal with the problem.
Using the Scrum methodology can work well in this phase to keep things on track although you should be wary of introducing new techniques into a failing, and now, hopefully, recovering, project. My advice would be to introduce ideas that help you meet the goal of completing the project but go slow with those that seem to cause problems. I’ve used some Scrum like methods but nothing formalized in some project recoveries. I’d like to hear from those of you who have used a formal Scrum methodology to recover a project.
Let me know if you have any questions or thoughts about this article by leaving me a comment or using the contact me button.
September 11th, 2007
If you want your next software development project to fail, and not just a small way but in big, spectacular, way, here are some sure fire steps for you to follow:
1. Set Unrealistic Goals
Your management says the project has to be done in 2 months. You know it can’t be done in any less than 6 and it’s probably more like 9 months. But, hey, they want it in 2 and you’re in no position to challenge them so why not just go ahead and agree to it. Your team won’t mind. After all, if they agree to work 80 hours a week they should be able to pull it off. Besides, you’ve just gotten the purchase of a brand new code generation tool approved. This will save loads of time in the project.
2. Staff Up Quickly
You need people on your team ASAP. Hire the first warm bodies your pal at Programmers-R-Us sends over for an interview. Your project has a tight schedule so you need somebody, anybody, on-board and ready to code. Don’t bother with having your team participate in the interview process or be too picky. If you do, you might lose the good candidates to other companies.
3. The More Documentation The Better
Require your team to document everything. You need a scribe to take down the minutes of each and every meeting and publish them afterwards. Every form must be filled out according to a mandated template taken from an antiquated mainframe methodology you learned in school or a NASA software development handbook you bought on eBay. Insist developers write out weekly, or even daily, status reports. You can never have too much data about a project. Ignore the whiners on your team who complain about being overloaded with useless work. They just don’t understand the benefits of good documentation.
4. You Can Always Make Up a Schedule Slip Later in the Project
If your project is falling behind it is always safe to assume that you can make up the difference later. People were just goofing off or getting into the project at first. Everybody knows that as the project progresses everyone gets more comfortable and productive. Just like in a distance race, everyone stores up enough energy for a big sprint at the end. Count on having a strong finish for your project.
5. Relax Your Standards To Shorten the Schedule
OK, so it looks like the document everything plan is not going to work out so well. The obvious answer is to do the opposite, scrap all documentation including any end user instructions or help files. That extra work can be done after the project is completed. Also, cut out fluff like integration and user testing, well managed source control and test systems and your other standard coding processes and procedures that just get in the way. Quality isn’t important, only completing the project on time is important.
If left to their own devices team members will goof off. It is your job to stay on them 24/7. If traffic is bad one morning, make a point of calling late team members on their cell phone every 2 minutes to gauge the progress of their commute. Who knows, they actually may be lounging at Starbucks rather than sitting in their car behind a jackknifed semi. Call them in the evening at home as well, particularly if they have the audacity to leave early, to discuss fine points of the project for 30 minutes or so. Use time management software to track each developer’s time in and out of the office and exactly what they’re working on throughout the day. Also, you should swing by every team member’s cubical 2 or more times a day to ask them about their progress. Feel free to offer your sage suggestions about whatever they’re working on. This lets them know how much you care.
7. Call a Daily Project Status Meetings
You should have at least one daily meeting to take the pulse of the project. This is best scheduled either first thing in the morning or very late in the afternoon. This helps insure everyone is arriving on time and not leaving early. Better yet, schedule a meeting for both times for a win-win situation. Every point of the schedule and the day’s work should be discussed in detail during these meetings. You have the room and the team’s attention for a full hour so why not use it to the fullest?
8. Threaten Team Members to Motivate Them
If your team is falling behind the problem is that you aren’t motivating them enough. You’re allowing them to goof off and fall behind! Put your project back on track by putting their feet to the fire. Let them know that if they don’t dedicate themselves wholly to the project they’ll be finding a new job. Question their competence as programmers and mention how anyone who doesn’t perform up to standards will be fired so as to spur them on to greater acheivement. You will be amazed at how motivated your team is after you take this approach.
9. Bring In More Programmers
That Brooks guy’s ideas might have applied way back in 70’s at IBM but they don’t apply in modern, Web 2.0, times. Screw the ‘Mythical Man Month’. Bringing in more programmers means more people coding and thus more getting done faster, simple as that. You could even have them work shifts using the same computers to save office space and equipment costs. You can easily find or invent a buzz word to describe what you’re doing to sell it to the team and your management. What a brilliant coup that would be!
10. Set Your Plan in Stone
Never, ever, back down on your vision of the project schedule or plan. You said 2 months with the new tool and you meant it. You know you have awesome estimation and project management skills. Don’t entertain any complaints about your choices in meetings. Anyone questioning your decision is being insubordinate and disrespectful and probably just looking for a way to slack off. How dare they question your competence and authority?
Special Bonus Idea
If you need good political cover for implementing these steps toward failure you need to tie them to a popular development and project management buzzword like Scrum, Agile, or Extreme Programming. All of these methods offer excellent cover to you both during and after the project. This shows your managers that you’re on top of the latest software development project management trends while your team are a bunch of disloyal whiners who can’t stand to have their cheese moved. Furthermore, when the project fails you will be recognized as a company expert of the method since you know what doesn’t work. Does it matter that you just ‘cargo culted’ these methods? No, not at all. You’re well on your way to being the next ‘pointy haired boss’ or Bill Lumbergh.
August 19th, 2007
Gaëtan Voyer-Perrault read my story entitled The 7 Steps of Software Development and posted his take on some aspects of it on his blog. In his opinion, Joe, the lead programmer in the story, deserved to be fired. In this post, I’m going to examine his opinion and do a little more revisiting of the article.
In his post, Gaëtan writes:
When you are the team lead, your job is the protection of your staff and the protection of the project that’s assigned to you.
I agree with this. I often refer to this as being the ’spear catcher’. As a lead, you are accountable to them just as you are accountable to your management. In the story, Joe’s lack of assertiveness and confidence in the lead role made him a push over for a very choleric boss as well as some co-workers. This led to the team being subjected to a very unpleasant work environment and to Joe’s eventual dismissal from his job.
However, the team was able to pull themselves together and produce a product, even if the design was bad. While I didn’t cover it in depth in the story, Joe did lead the team adequately when it came to developing the program. They built it according to the flawed plan they were given within a reasonable time frame. We can assume that when it came to the actual programming work Joe performed that part of his job satisfactorily.
Joe had not had these types of problem on this project during his previous projects over his 6 years with the company. We might assume that the previous development manager, who Joe got along with well, had acted in a project manager type role that insulated him from these kinds of problems. Joe wasn’t prepared to take on these additional aspects of his job and he failed at it.
Gaëtan continues on concerning Joe’s problems getting a meeting with the project sponsor:
If you don’t get a reply in 2 days, you e-mail Brian’s superior and you forward him all previous e-mails.
This leads into a point that I covered in the story, the leadership vacuum at the company. Brian, who was a second tier manager, reported directly to the CEO. This left the IT development organization with nowhere to go if there was a problem since Phil, the CEO, rarely had time to deal with small problems that bubbled up. Instead he would delegate them back down the chain of command and he trusted his managers to make the right choices. Because of this, Brian’s poor management techniques didn’t become an issue until a CIO was hired, well after Joe had been fired.
Could Joe have made a difference by taking more initiative as Gaëtan suggests? Yes, I think so. He might have still been out of a job but he would have fought a good fight and not wimped out as he did almost to the end in the story.
Gaëtan suggests that Joe could take legal action
Joe should have phone numbers on hand for all government-related agencies and for his lawyer and he needs to walk into the HR office and tell them that the bullying ends as of his visit.
Unfortunately, in my experience I’ve found that legal action or the threat of it rarely works against this kind of non-physical/non-sexual/non-racial bullying. Work place bullies like Brian usually know just how far they can push it to avoid trouble since most are well practiced at their ‘art’. You usually have to wait until they cross the line, making a racial epithet, a suggestive comment or lecherous grab, or push or shove, before you can take successful action.
Finally, should Joe have been fired? Gaëtan thinks he should have been. While I think it was the inevitable end result in this case, Joe was a valuable asset to the company. By firing him the company lost someone with key knowledge that could not be easily replaced. Perhaps his social skills were very lacking, but was this a good reason to fire someone? Unfortunately, often it is the reason many a skilled programmer loses their job.
So, what could the company have done to have avoided this fiasco, other than not hiring a major jerk like Brian?
- Hire Product/Project Manager(s) to work within IT and with project sponsors to improve communication within the company.
- Make sure that all positions in the management hierarchy are filled within a reasonable time with qualified people while insuring that communication flows well while vacancies are present.
- Offer personal development training to employees who are promoted into a managerial role, even a minor one like team lead.
- Have an executive committee that closely reviews new project proposals to insure that they’re feasible.
What should Joe have done to avoid his fate? Gaëtan had several suggestions, but what they distilled down to was that Joe should have been more assertive. I agree with that and I do recommend that socially challenged programmers do things that will help them in this area. This might be taking karate lessons, joining Toastmasters, getting individualized counseling, or something else that helps you improve your skills in this area.
July 13th, 2007
When we’re developing software we should never lose sight of the fact that it’s being developed to solve real problems and to fill needs potential users have. The end user of your program is the most important person in your project.
Often we do forget them and get hung up in writing the coolest new routine, saving a bit or processor cycle here or there, or doing other things to please ourselves. Even worse, some developers choose to punish their end users by inflicting things like forced color and font selections, forced screen sizes, non-standard Windows behaviors, crazy lockouts, and other such nonsense.
If you’re in a corporate environment, talk to your expected users regularly. Stay on top of the situation because things can change rapidly. If they work in a different location than you, plan field trips to go visit them. You can learn a lot just by observing their day-to-day process and talking to them about what would make their work easier and more efficient. You can also determine if the cool features you want to implement will annoy them greatly or be of great benefit.
If you’re doing commercial software or outsourced software it may be hard for you to talk to your anticipated users. In this case, your testing should include reality checks from people outside the project. Let them test the program from the perspective of a user. They will often notice weak areas or user interface problems that you, being close to the software, miss.
Also, don’t be afraid to give select users sneak peaks and alpha or beta test versions of your program. You have to use some care in selecting who will participate in these tests but the benefits to you and your program can be enormous. The earlier in your development process that you can deliver even a rough or incomplete version the better because user feedback can help put you on the right path to developing the best program for them.
If you’re a project leader or manager, allow your team the freedom to work with end users directly and encourage managers in sponsoring departments or companies to allow this as well. The reward will be higher quality software that users enjoy using.
May 23rd, 2007