- App Projects Are Not Small and Easy
- Apps Are Not Easy to Program
- Poor Skill Set Fit
- If You Get a Good Developer, You Still Have to Worry
- The Idea Is Not More Important Than the Execution
- Unwillingness to Delegate: Micromanaging
- Bikeshedding
- Poorly Defined Requirements
- Out-of-Date Requirements Documentation
- Constantly Changing Requirements
- Leaving the Worst for Last
- Cost Overruns
- That Last 10%
- The Whack-a-Mole Problem
- Poor Communication
- Abdication of the Management Process
- Wrapping Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
Poor Communication
Poor communication dooms any software project, but mobile projects, with their relatively smaller budgets, shorter time lines, and often remote teams are particularly susceptible. The solution, though, is not more meetings. I’ve been on projects that had conference calls every day, and the communication was still horrible. In fact, lots of meetings often make it worse because everyone thinks that if nothing came up on the conference call, everything must be going fine, when that’s not necessarily the case at all.
It’s in vogue these days for every project to have a daily stand-up meeting. I’m not going to tell you not to have one; there’s nothing inherently wrong with those meetings. What I am going to tell you is that a daily stand-up doesn’t give you information about how well the work is being done or whether the whole project is on track. A daily stand-up just tells you what everyone is working on that day, and what, if anything, they’re waiting on to be able to complete their current tasks.
And then there are project status meetings where everyone says that his or her part of the project is going just fine. Again, these aren’t particularly useful.
Making the Most of Meetings
As with requirements, good communication is all about details. And to prompt your developers to give you good details, you have to ask the right questions. The questions usually asked at meetings are either two narrow (“What are you doing today?”) or too vague (“Is your part of the project going okay?”).
One recommendation is that you should never have a project meeting without a written agenda, and the agenda should be circulated to everyone who will attend the meeting in advance to give people time to think about what they need to say.
The agenda should ask the questions that you as the app creator need answered, like “What’s the biggest risk to this project as you see it right now?” or “What’s the most likely thing that you think could go wrong on this project, and what can be done about it?” or even “What decisions need to be made in order to complete the tasks you are currently working on, and what alternatives are there for each decision?” These kinds of questions will prompt discussion of the details that you need to know.
Then, once the meeting is over, make sure that someone writes up a summary of what happened in the meeting and distributes it to the group. These meeting notes become very useful later in the project when confusion arises.
Examine the Project’s Artifacts and Ask Questions Contemporaneously
Another way to facilitate communication is to look at what’s happening on a project and ask questions about it. I try to review changes to the source control repository and bug trackers at least every day or two during a project to keep up to date with what’s going on. (See Chapter 10, “Understanding What You’re Getting,” for how to do this.) If I have any questions after reading the commit messages on the code check-ins or the updates to the bugs, I send someone email and ask for clarification. If the developers know that they’re going to be contacted if they don’t write clear commit messages or bug updates, they eventually put more thought into what they write, and the quality of that information goes way up. (There are many discussions of source control and bug trackers throughout this book, so don’t worry if these terms are unfamiliar right now.)
It’s important to ask these questions soon after the developer does the work. If you wait a week or two (or maybe even a few days), the developer might not remember as well what he or she was doing, and the quality of the explanation will suffer.
Insist on Getting a Plan
Periodically (at least weekly), you need to insist on getting a plan that shows what needs to be done between now and the end of the project, with specific details about what the next few steps are. Much of the report will be the same from week to week, but as you get more and more of these reports, you should see how the things that have been done have lined up with what the plan had previously said was going to happen. As with everything else, make sure you understand what you are looking at and ask detailed questions until you do.
If at all possible, I recommend getting these plans in the form of Gantt charts (which are discussed in Chapter 5, “Finding the Right Tools,” and Chapter 9, “Managing to Milestones”).