The end game, the time right before a project finishes, can be difficult. Keep things manageable by focusing the team: turn off  e-mail and voice-mail. Beyond huddles, cancel all non-essential meetings. It also helps to keep the work in a known state. With multiple people making changes to a project, ensure that the details are pulling together.  In software development, this means building the entire application daily. 

It's tempting to strive for total perfection as the project is nearing completion, but stop and ask, "does this problem need to be fixed?" In software, sometimes with small problems the mere act of fixing the bug introduces more bugs! Avoid this by distinguishing the small problems that can be fixed at a later time from those that are truly critical.  

It goes without saying (but here I go), that the end of the project is not the time to solicit and add more to the project. This is the time to nail the requirements and "get 'er done!" If a project deliverable date must be changed, however, don't exchange one bad date for another. Instead, get the team involved in setting a new date that is realistic and then hit it. . . no matter what. 

Tom's Takeaway: Project end games can be smooth if the team focuses, makes strategic decisions about critical fixes and focuses on meeting the deadline. Be sure to celebrate when the project is delivered too...whether a formal dinner or a beer out with the team, it makes a difference and will be remembered the next time you're in "crunch mode."

An old adage, "plan your work; work your plan" has enduring business wisdom for today. Following a planned process makes particularly good sense in the constantly changing arena of software development.  

To keep work from becoming erratic or chaotic, we need process.  For software development, if you have a consulting partner, look to them for process guidance.  That said, while you may start with a partner's process, in the end, make it your own by continually improving upon it. 

I believe any smart process includes continually seeking and incorporating improvement based on feedback as well as just looking at what works.  At the end of each project, do a post-mortem.  Throughout the process, don't blame if mistakes occurred.  Instead, ask "what could be done differently next time to make it better?" 

Tom's Takeaway:  Work most effectively by following -- and continuously improving -- the work process. 

IBM built an empire on the word "think." Why is that concept so radical to many?  Perhaps because we spend much of our time "doing" in an effort to seem busy and productive. But thinking is the most important work we can do and it's key to delivering projects on time. To get people thinking and focused on a project:

• Encourage team members to constantly ask, "What could be done today that would the greatest impact on the future of the project?"
• Keep meeting, including daily huddles, focused. Set meetings for first or last thing in the day or right before lunch.
• Make meetings productive by encouraging decision-makers to make decisions when necessary.
• Encourage balance by keeping the work within the workday. By this I mean don't encourage an environment where "crunch time" is "business as usual." If you do, "crunch time" loses its meaning.
• Remember: there is no silver bullet. Success is the result of a series of tasks done consistently and well. 

Tom's Takeaway:  Don't get caught in a mindless activity trap. Instead, take time each day to think about the project and make decisions thoughtfully. Encourage your team to keep balance by working smart during the workday and saving "crunch time" for the real crunch periods. It's consistency over time that makes the real difference in the end.

In fast-moving environments--most companies today--daily huddles can keep communication consistent and effective. We use huddles and keep them to 15 minutes max. Each team member gives an update and a "daily number" is shared, which measures the overall health of the project. If you have six data consecutive points in any direction you have identified a trend. Each member also shares a "stuck item," which highlights problematic areas early and enables the slaying of monsters while they're still small. Huddles can cascade to keep everyone on the same page. For example, it there are three project teams working on the overall project, the separate project teams have a huddle followed by a huddle of three project teams and their superior. Tom's Takeaway: It can be tempting to forgo communication tools, like huddles, especially when you're in the end game and near project completion. Don't give into this temptation because this is when clear and consistent communication is most critical to project success.

At the start of a project with the team is in place, it's time for everyone to roll up their sleeves and define the problem to be solved. This may strike some as an unnecessary step, even a waste of time. Let me assure you: it's essential. There's an adage, "a problem defined is half solved." I believe this is especially true in software development. In fact, an IBM study found that well-defined objectives were the number one factor in successful projects.

• A good project definition should include: 
• A project plan defining the vision, Critical Success Factors and areas of responsibility. 
• A requirements document defining when the project is complete. 
• A prototype, mockup or demo that provides a visual tool for clearing up misunderstandings. 
• A Gantt chart or Sprint Plan stating who, when, what and related interdependencies. 
• A risk plan defining what might go wrong and what to do if it does.

Tom's Takeaway: Beginning a project without a clear definition and plan is like building a house without a blueprint.