- Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.
- The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal.
Posts Tagged: projects
This is an overview of the entire world of user experience (UX) design from the point of view of a dedicated UX practitioner. It covers the UX side of project management, client interaction, design, development, and testing. Despite the broad coverage, its focus on the practitioner means it goes into a bit more depth than many such books.
The book includes good discussions of personas, user-centered design, user testing, wireframes, prototyping and more. Continue reading “A Project Guide to UX Design — Russ Unger & Carolyn Chandler” →
Bored with what you’re doing now? May I present the next thing:
The Cult of Next Manifesto
- There are three states of being. Not knowing, action and next.
- Accept that everything is a draft. It helps to get to the next thing.
- Done is not enough.
- Pretending you know what you’re doing is almost the same as knowing what you are doing, so just pretend you know what you’re doing and go to the next thing.
- Banish procrastination. If you wait more than a week to get an idea done, go to the next thing.
- The point of being done is not to finish but to get to the next thing.
- Once you’re done you can go to the next thing.
- Laugh at perfection. It’s boring and keeps you from the next thing.
- People without dirty hands are wrong. Getting to the next thing makes you right.
- Failure means you can go to the next thing. So do mistakes.
- Destruction means you can go to the next thing.
- If you have an idea and publish it on the internet, you can go to the next thing.
Here is a simple documentation strategy that emphasises minimal yet useful documentation for small to medium sized software projects. The goal is to ensure that writing the documentation is not too arduous, and that the documents are useful both during the project and after it is finished.
Traditionally, software development organisations deliver several documents, including Requirements, Functional Design and Technical Design. In this approach, each document is heavily dependent on the previous one. This means the documentation is often inconsistent. For example, if the FD needs to be revised, the TD may need updating too.
Part of this comes from the idea of forcing the customer to make all judgement calls. This can be slow. It’s better in many cases for the development team to make the call themselves, based on their understanding of customer requirements, and communicate this to the customer. The customer can then intervene if they really need to — and they won’t need to if the developers understand the actual requirements (as opposed to the documented requirements).
Every development project should have an architect. This person determines the way the software is put together, and specifies policies and standards for design and coding. For example:
- Organisation of code â€“ layers and the interfaces between them, (e.g. function calls and exceptions)
- Directory structures of source code
- Organisation of common code â€“ exception classes, utility routines, logging, etc.