Speed Up Your Next Software Project with the "Morale Project Plan"

Working on software and falling behind on the project schedule? Is your customer frustrated already? Try my gameplan. It may improve the morale of your customers as well as your developers, and may unstick a stuck project.

1. DEMO. You really need to think through all the nuances of the app. Sometimes projects are mired down because of discoveries. If you have time, use a slideshow drawing program to build sort of a demonstration of how the application would work, or throw it together as rapidly and as sloppy as you can in web pages and static test data to sort of get the point across and think through those discoveries.


2. TECHNOLOGY LAB. If you have an experimental technology or a few that may be necessary for your application, spend no more than 3 days per technology trying to work out the kinks and decide on the application's direction based on the results.


3. FUNCTIONAL SPEC. This is really critical and I require one on all my applications. If I can't get agreement for time to iron out one, then I tell you that this is not a project I want to work on. Working with the stakeholders, write a functional specification to explain every required feature of the application. Spend no more than one day, initially, and then deliver it to the stakeholders as a draft. Let it resonate on the mind a couple days, get some feedback, and then conclude with a final draft on another day. Of course you'll have feature creep, I'm sure, but this will help minimize it a great deal.


4. USE CASE. This is where you normally write down all the possible threads of traffic from users visiting your application to do a set of tasks. Instead of spending a lot of time on this, just think up on use case that would demonstrate the largest set of features, complete from launch, login (if you use that), and the path among your features until the task is complete. It needs to have a real world example, but not a long one. Spend no more than one day building this with the stakeholders.


5. PROJECT PLAN. You need to build a project plan. Do you need to build one in a project application? No, actually, you don't. A spreadsheet will do just fine in most cases unless your stakeholders are used to interacting with people who have project applications. Of course you're probably going to slide a little on time, or have to make adjustments as more discoveries are made, but at least you have something to strive for. Here's how I do mine.








• Start your plan by taking the functional specification and group features by page or screen in your application.


• Now sort these features in chronological order that would flow along the path of the use case you recorded, such as login, come to a main page, click "New Ticket", fill out a form, post it, read it, update it, resolve it, etc. That's an example of your use case.


• If you have previous projects you have done, see if you can leverage that to decide how much time you think you'll need for each project step. Note also that if you give a feature task to someone else, you are probably going to need to tack on 2 extra hours per feature, maximum, for everyone you pass on. This isn't always the case, but is usually the case in my experience.


• If you don't know how much time a task will take, then give it 4 hours and let the stakeholders know which ones are slight unknowns. I recommend setting up checkpoint times with the stakeholders to explain increased productivity or the need for more slack time, so that you can come to a more realistic timeframe for a project conclusion. You'll also need this on the next project you do.


• Now add up the total time and divide it into sections of (A) 20%, (B) 50%, (C) 20%, and (D) 10%. What do these letters and numbers mean? Well, before I tell you these numbers, realize that you will be testing your application as you do each feature, so testing is already built-in. As for the numbers and letters, these are sections of the project. The letters are the project section, and the number is the time you will spend to complete that section. The project will move in alphabetical order with these sections, starting with A, and you will have checkpoints in between except in Section B, where you will have a checkpoint before it, in the middle of it, and at the conclusion of it. The checkpoint will be when you meet with the stakeholders to explain progress and discuss problems and solutions, along with risks and risk management. In Section A, you will rapidly write the software to implement as much of the Use Case that you recorded. HOWEVER, don't get mired down in the tough, difficult features of this Use Case -- turn it out as best you can so that you can deliver a good customer demo at the first checkpoint. In Section B, AND THIS IS KEY, this is where you will resort the project schedule by uncompleted features that will provide the largest visual contribution to the project. For instance, if I'm writing a criminal records search program, then I might sort to the top of this list the administration pages because, as an example, they might provide a large set of features that the end user (in this case the administrator) visually sees. I might follow that with an options page where end users can choose a whole variety of search options, or a calendar where I can see when my lengthy query requests might be processed by other company departments. It's all up to you to decide this. What Section B focuses on is programmer motivation so that they will feel like they're getting something done and will make the customer feel more at ease during checkpoints. However, saying this, realize that Section B is there you also do not get mired down in difficult code. Instead, you simply try to knock out functionality on an 80% functionality per feature rule. Section C, however, is a bit tougher. This is where you go back and complete the 20% functionality on features that you did not implement completely. Section D is where you do final testing and completion of the application.


• Based on what you discovered by the process of building these sections, adjust your project schedule timeline so that it accommodates these sections properly. You should also adjust the times if necessary.








6. PIXELS. Some developers I've interacted with worry about how they're doing something as small as whether it's the right number of pixels in width in a graphic element on the screen, or the minutia of how they implement an OOP concept. If you're in Sections A and B of the project plan timeline, this is not where you want to permit this to happen. Instead, let that happen in Section C. Otherwise, you may lose developer morale and cause timeline fear with your stakeholders.


7. DOCUMENTATION. Some people like to document the application as they go. I find this quite aggravating and disruptive to the train of thought to developers. Besides, with the usual feature creep and discoveries of problems that require workarounds, there's a lot of wasteful time that's going to occur, rewriting the documentation. Instead, I prefer to bring in the tech writers to write the help files (or pages) along with the hosting documentation, installation documentation, reprogramming and systems integration documentation (should you be building a kind of SDK framework like your own CRM package), administration documentation, end user usage documentation, and troubleshooting documentation. Of course, you'll need to calculate this ahead of time and include it in the project schedule.


8. FOLLOW UPS. When the project is complete and is implemented with the stakeholders, regroup and record those lessons learned, reusable frameworks, technologies, and ideas for future projects, and try to record how long it really took to complete each task on the project schedule. Consider also, if this is applicable, how long it took for a new developer to catch on while working with you on the project, and how the timeline must adjujst for that. Going forward, reuse this information and it will really help with your next project plan.


9. GETTING FASTER. On your next project after this one, I can almost guarantee you that if you reuse large chunks of old frameworks, technologies, and concepts from previous projects, and reuse key team players from successful projects, you can probably shave off 2 weeks off the time it takes to complete your next project.


10. THE NEXT VERSION. On your next version, the stakeholders will likely have more features they want to add, or to rework problems on existing features. I recommend that you do not accommodate all those in the same version. Instead, split this out over two versions. Give the customer 80% of what they want in the next version (1.5), and the 100% of what they want in 2.0. Why? Because you'll probably want to rewrite the application between it's current version and version 1.5, and this will take a good amount of time. You'll probably want to make more readable code and increase application performance. Do you need to tell the stakeholders this, though? No, you don't. Just let them know that you'll release the package twice so that they can be functional with 80% of the new features initially, and then 100% of the features eventually.

SUMMARY
If you're skimming this, the most important thing I think you can do is to follow the rules I have specified for a Section A and Section B in the project. Section A focuses on the most common stakeholder walkthrough scenario and trying to provide at least 80% of that functionality, not getting mired down in the tough parts. Section B is where you help the developers overcome potential frustration with the application where they may feel it's too tough to pull off on the specified timeframe, or may lack motivation simply because they're overworked. Section B is where you start knocking out features by their largest visual contribution. The more of these you accomplish, the increased morale you will have with the developers and with the stakeholders. Everything else is where you sweat the small details and fix the remaining bugs.

I also believe in a rapid prototype, a technology test period, a simple use case design, a project plan, checkpoint periods with the stakeholder, documentation at the end instead of being integral with the project, and follow ups to identify ways to get faster on future projects with reusable frameworks, technologies, and concepts, in addition to the potential to reuse certain developers. I also have a unique spin on how to implement the next version so that you can have more readable code and a performance boost in addition to whatever the stakeholders want.