Archive for April, 2008
what’s the cost of a toner cartridge?
what is the price? $70-80? maybe a little more depending on the model of your printer and the kind of toner (color, or b/w). but what’s the cost of it? not many people stop to think about how the little things turn into big things. what seems like a small inconvenience can actually be a huge problem in disguise.
dare i say it — the cost of a used toner cartridge is more than the cost of a new one.
you’re a worker. you work hard every day. you’ve been working especially hard lately because there’s a lot of important work going on and you have to get it all done on time. so you drive into work one day and you log on to your computer, you check emails and some are worthwhile but most of them aren’t. then you get a phone call from your boss that a certain work item needs to get done, and it needs to be done yesterday.
hurriedly you start working and crunch numbers, or design a new prototype with changes from the client, or focus on a hardware emergency, and you get it done! crisis averted … or so you think.
build a microwave oven but create a nuclear device
i’ve mentioned in a previous post how it’s important to create systems based on standards. i even went so far as to say they really ought to be based on open standards (php, xml, etc.) and i really mean that.
now to go along with that, a current trend that i honestly feel you’ll see much more of is a move towards more and more open-source projects and systems in the workplace. i love the open source community — i really do! they’ve given me my instant messenger clients for the last 6 years, my WordPress that i use to create this blog, my web-based collaborative software that i use to track my work and milestones when on the job, and a lot more!
the point is no single developer is as great as a community of developers.
standardize!
if this one seems brilliantly simple … it’s because it is. businesses should be standardized with 1 major, crucial, unspeakably important caveat to it: unless it doesn’t make sense.
i say that because many times you will come across something that you can’t put in a box, and if you try wrapping it up in cardboard you’re going to fail. standardize only where standardization makes sense, and unlike cardboard itself, be flexible!
i completely understand that while i enjoy running around by the seat of my pants (life is more exciting that way!) being “reckless” like that in the business world is probably not the best idea. standardizing processes, technologies, documentation, etc. all help — in the long run — to reduce costs, to reduce effort spent, and (hopefully) to increase quality. however, as i mentioned, it’s critical to keep an open mind to everything. business changes. the work you do will change. therefore your standards are also going to have to change along with it. if someone comes to you saying, “i think there’s a better way we can do this..” the following are not acceptable answers:
KISS
it’s perhaps the most basic of principles, and i partially hit on some primary ideas in my last posting, but it’s something that i just have to say:
keep it simple, stupid!
i’m from the school of thought that less is more. i believe in the cool serenity that is a simple design. simple means it’s easier; easier to understand (and explain!), easier to do, easier to manage, and — the part not many people think about — easier to maintain!
this is true for many things.
- the way you design your solutions
- the way you develop your systems
- the way you draft your documents
- and more!
define what you’re doing before you do it
from the time we’re little, we’re taught 2 lessons:
- respect your elders
- because i told you so
that first lesson can more appropriately mean, “respect those people with more authority than you” and the second as “because you’re not in a position to oppose this.” so many people grow up — go through school, life, and everything — and adhere to those rules. they enable people to lead, not because they themselves can’t lead, but because they we’re always told to follow.
so what’s all this have to do with anything? bottom line: if you tell someone to do something, chances are they’ll do it — if they know how to or not.
as a team leader, project manager, small work manager — whatever your title is — you hold power to tell people to do things that they feel they’re not allowed to challenge. even if you say, “let me know if you have any issues” people generally won’t because that’s both, (a) an admission of a lack of competence, and (b) a waste of time because even if they had a problem, they always ask themselves “would my bringing this up really change the situation?”
when we create project documents to outline the scope, goals, etc. it is vitally important that we define exactly what needs to happen before telling someone to do it.
it sounds completely stupid because it’s rather common sense, but you’d be surprised how many people don’t do it. project documents need to be descriptive, easily understood, and all goals — both functional and technical — ought to be clearly marked out. scope documents (or sections about the scope inside an overall project plan document) are not 10th grade word problems. all the requirements for work should be expressly stated.
recent comments