Project Planning and Management
1. Hear the Customer’s Voice
Identify the internal and external customers that will give thumbs up or down on your deliverables. Prove that you’ve heard what they’ve said. In meetings, write down important, direct quotes. Subsequently, prove to them that you were listening by demonstrating how you addressed that specific concern.
When everyone on the team is noting these types of issues, gather them in a list, prioritize them, and keep it in view of every team member. During technical discussions, particularly those involving user experience issues, refer to items in this list to advance or reduce points of view. Identify when the customer is asking for mutually exclusive solutions and clearly explain why one or the other option can be delivered but not both. No voice should be louder than the customer’s; the project team must hear it clearly and accurately.
2. Microsoft Office Skills
Learn to use Words’ templates, review\comments, table of contents, index, and multi-level list tools. Use templates that limit all format and styling to named styles. By using named templates with specified styles, documents from various authors can be concatenated, cut, and pasted without creating formatting headaches. Numbering will be consistent, and graphics, tables, and captions retain common presentation. If authors cannot write without consistent formatting, accurate styles, proper spelling, grammar, and punctuation get someone else to write the document.
Learn how to display complicated data in a meaningful way. Learn to build visibly appealing tables with proper heading, shading, and calculations using Excel. Use Excel charts to design simple but meaningful displays of meaningful data. For example, use a two-dimensional chart for two-dimensional data. Learn to embed these charts in Word and include the raw data in appendices.
PowerPoint is easy, but the ability to present meaningful data requires far greater resolution than your average slide. Learn to use the advanced Visio templates for business processes, use cases, UML, Class Diagrams, and Object Models. Keep your visuals consistent and minimize everything that is format and not data. Avoid flashy, canned, and cliché but otherwise meaningless “noise” in slides, handouts, and reports. Include tables of meaningful data as appendices and refer to them in the body of text and in your presentations.
3. Document Requirements as They are Discovered
Requirements exist regardless of whether or not they are written in some document that nobody will read. If the customer thinks they’re buying a roller coaster and you deliver a tire swing, everybody loses. The requirements the author faces the challenges of translating the customer’s expectations to verbiage. This is not the time for scope management; it’s the time for clarity and accuracy.
The optimum requirements document eliminates all uncertainty from the reader’s mind about what will be delivered. On the other hand, a document written to that standard can be difficult to write and, therefore, very expensive. Learn when requirement documents can rule out options in the customer’s mind as well as when simple proof of concepts, use cases, and wireframes will suffice.
Requirements mature as they are sized, and solutions are estimated; this is the time for scope management. On the other hand, when business analysts and developers interact to optimize the solution, be sure that scope remains static, neither creeping nor retreating. Note when technical constraints impose business rules on use cases. Document those rules and gain customer’s approval resetting their expectations. Manage the requirement life-cycle by logging changes in requirements as the need arises.
After initial reviews, changes to requirements should require input and approval from project leadership. Avoid reopening requirements and technical designs after the initial review stages have created an expectation of how things will work among a group of stakeholders when that group may be difficult to reassemble later. Avoid spending time writing better requirements when you could spend time writing better code.
4. Commit it to (Virtual) Paper
If a project can’t run on the exchange of electronic documents after the first few discussions, somebody needs help with documentation. If you talk about it once, write it down. If you talk about it a second time, edit the original to account for any new knowledge. When someone is smart enough to run a whiteboard marker, they should be smart enough to distribute the final outcome of the session in Visio before the whiteboard is erased. If they are not, then figure out who is best at Visio and let them do the diagrams using a consistent format and shape set. Discussions should be about what is in which document not about what is in the document. If you’re going to discuss what’s in the document, do it in the document by inserting comments and tracking changes.
If meetings consume most of the team leadership’s day, they are not leading; they are being led. Documents written in 30 minutes can be read in 10 but can take two hours to discuss and more if they are poorly written and do not present a clear narrative meeting a defined objective. If people are not reading documents, they need to be written more effectively. The document’s objective should be covered on the title page with its title and sub-title, perhaps adding a blurb of 20 words or less. If documents are unreadable, if diagrams are confusing, if things don’t make immediate sense, either the reader needs training or the author needs to be replaced. If a document or diagram evokes more than a polite discussion or nod of approval, if it elicits more than one or two comments or corrections per page, it is poorly authored. Project leadership should track the document storage facility as it matures, continuously weeding out the garbage and tracking the owner and maturity of each document.
5. Make and Share an Index of Topics
These topics are the components of the final solution. Articulate them from the user’s point of view. Make the business analysts and development managers refer to these specific topics when they discuss the solution. Consider adding a new topic only when a discussion doesn’t fit into one of the components. If a discussion isn’t relevant to a specific user’s activities, maybe you’ve missed a user segment, or you’re talking about solutions that are not required.
Establish and maintain naming conventions from the list of topics all the way down to the namespaces, the classes, and the dll’s that you’ll deliver listing with their contents where everyone can see them. Don’t add a new one until everyone on the team understands its objective. Review the list regularly to be sure similar functions are not duplicated in code. Names should be informative and not cryptic. If you’re going to name it once and a number of people are going to use it a number of times, go ahead and give it a verbose name that allows people to know what you’re talking about avoiding all but the most obvious abbreviations and acronyms.
6. Mind the Vocabulary and Share the Narrative
Keep a single, running list of vocabulary words and their definitions. Words should connote their dictionary meaning as much as possible; Avoid using arcane jargon and shop talk to name objects. Avoid using two words to describe the same thing. Share a single list of definitions, abbreviations, and acronyms. Add new items as they are discovered and finalized. Never duplicate these lists. Append this list to each document as it is finalized. Do not allow discussions to proceed when participants are using the wrong vocabulary; explain the correct phraseology, and expect it to be used going forward.
Likewise, the application narrative from the user’s point of view should be leakproof; every question that starts “What happens when the user…” should be answered. Index use cases based on the user’s objective. Use cases should exhaust this list of objectives and detail the objective and identify the possible points of failure that will prohibit the user from meeting that objective.
When participants argue a point, the result should be unconditional surrender; make sure it ends with a winner and a loser. Often people hear what others are saying only when it supports their argument; these discussions are inherently political. When two participants disagree, they argue and try to persuade and eventually quit both, leaving convinced that they won the argument. Immediately they will begin lobbying the chain of command offline in an attempt to establish their point of view as accepted policy. To avoid this, when discussions include opposing points of view, make clear who wins and who loses. Assuming you won when I didn’t admit defeat is a breach of protocol.
As the use cases mature, an application narrative will evolve, allowing everyone on the team to recognize the purpose and the importance of the pieces they are working on. Build this model office in the mind of each team member and make sure they are building items to make that office work.
7. Separate Technical Activities from Creative Activities
Ignore style sheets and graphics during technical development cycles. Ignore technical constraints during creative development cycles. When creative resources provide interface specifications, follow them in exacting detail and don’t change them without your gaining your creative resource’s input. Allow information architects to provide initial taxonomies and allow that taxonomy to mature with the project. Don’t build reference tables, parent/child relationships, many-to-many relationships without the information architect’s input. The application should work in plain black text on a white screen. Likewise, the application should look like the bomb without doing anything. To technical people, the objective should be efficiency, to creative people, user experience.
8. Ban Content from Email
Use email to arrange for meetings and share agendas, Use emails to seek out help. Use emails to share links to documents and lists of links to documents. Use emails to communicate project metadata like pending dates, action reviews, and people news. Use smart subjects for emails.
Do not use email for lists of issues, tasks, or discussions. Instead, point your audience to the documents that manage these items, whether it’s a spreadsheet, a file share, or a real issue tracker\discussion board. When documents are ready for review, send links to the documents not attached documents.
Also, minimize your audience for both messages and meetings. Assume that meeting requests will be accepted without in-depth analysis of your invitation; if attendees need to be prepared, send a separate email ahead of time with a suitable subject line and links to the necessary documents.
Any team member that creates a list of comments of more than three items and emails it to more than three people should be reprimanded. Any team member that responds to such an email by interlacing their comments into the previous comments and emailing it to a larger audience should have their email account deleted. Any issue that might evoke a response should be written to a discussion document, discussion board, or other moderated, trackable resource. Use this resource to generate your FAQs as documents are finalized.
