So Right Right now is happening, soon. Once I grind out the current batch of projects, I’ll be on track to get the site up and launch it in earnest. I’ve been using Basecamp and I just started using Highrise.
I really, really like Heap and Torch, but they need a level of polish that they don’t currently have. Those applications are so tauntingly close to perfect in many ways that it’s hard to skip them, but they’re not ready yet. Torch particularly lags behind heap in what it can do…so I have to use something else because I have to have software that just simply works. I predict though, that if the current usability issues can be solved, that Heap + Torch will be world-beatingly good. An email based ecosystem rules. I just don’t happen to agree with the way that they perceive to do lists at present.
And Basecamp is oxygen simple. I don’t like the way that it perceives due days, and the lack of ability to globally assign all due dates in a list to some later date. But it’s easy enough to use, and I’m somewhat over my hotkey bias. The hotkey bias was based on the fact that I used a celeron based dying, windows PC, and a miss click with my mouse would cause me to be in some neverland for 15 minutes.
But what I wanted to write about today was process stuff. More aptly, designing a pre-and post project checklist that gets you where you’re going and ensures your company learns and grows and gets more valuable over time. Anyway, here is the current ‘post project’ wrap up that we’ll do on each project:
- final QC Review: spelling, all bullet points and loose code tied down.
- Change any passwords shared externally and record passwords
- Evaluate team members based on: hitting deadlines, communication
- Evaluate areas where we can improve on future projects.
- Thank all team members for participation and share evaluation
- see if there are further projects that we can help with.
- solicit & record feedback from team members on how to improve process
- look at things that were in this spec that can be added to general templates.
- Look to see if any opportunities for mutual profit exist as a result of this project.
- Gain client testimonial whenever possible. If not possible, ask what we’d have to earn
- to get one.
- Send all files to client in a zip file for their records and future use.
- Create Project P+L.
- Do we have any permanent resources in project that are reusable?
- Add resources to code library.
- Blog Project case study: Start Date, Due Date, Done Date, Team Members, Client
- Happy?
This is not exhaustive, and we don’t want to be plagued with mission creep. my guess is that this list will get bigger for a while and then get really small. But it’s what to think about because when we do a project, we must get better at our jobs, each time.
There is a perverse incentive that programmers (who need jobs) to be sluggish with projects. By saying that someone doesn’t intend to work somewhere very long, it eliminates that. By getting world class people that are using this stuff to fund and further their careers (in lieu of people that can’t get jobs elsewhere), we’re saying: hey, we’re going to improve your processes and systems, we’re leaving, and we’re unbiased because, while we’ll honor your money, we’re not in it to siphon money from you to us. We’re here to kick ass and make you better, and we’ll be gone. We hope to be invited back, but, a long term thing just isn’t us. Oh, yeah, and we’re not really into feature creep, we want to give you kick ass work quickly.
Anyway, that’s where I’m at with this thing, and I am actually executing and funding it so we’ll break out and start networking and getting customers.
Related posts:
