Critical Path Newsletter
Can your candidate spot missing requirements?
There may be software project managers in the world who can define every last technical requirement of the tasks he assigns, quickly and on the fly. I’m not one of them. With time pressure and daily distractions, there will always be missing requirements in the tasks I assign.
The “T” word 2: Trustworthiness
In the last Critical Path, I talked about how the lack of trust contributed to the failure of a project at Macadamian. Today I'd like to talk about how you ensure a partner deserves that trust; how you know they're trustworthy.
The T Word
At Macadamian, we’ve always known that trust is a vital component of the outsourcing relationship. In this Critical Path and the next one, we will talk about a couple different aspects of the “T” word. First, a little story about why trust in the outsourcing relationship is so important. Sadly, the story is unhappy—and true.
Reviewing an estimate with limited time and expertise
Your senior developer comes into your office with that estimate for the highly technical and complex feature that would be great to have in the next release. He’s estimated six weeks. There are six weeks and one day left in the cycle. You need to make sure the estimate is accurate, but you’ve never touched that technology before.
The patch a day principle
I met with Ovidiu this week, a new developer in our Romanian office, for his first week training.
“Once you start development,” I said, “you submit one patch a day.”
Snow shoveling theory II: Contracting out
When I was helping Martin Larochelle with his "Snow shoveling theory of software development" Critical Path, I flippantly suggested adding the following line “Some folks contracted out their snow removal (We’ve always said you should outsource non-core competencies. Very efficient!)”.
The snow shoveling theory of software development
Shoveling 30cm of snow off your driveway in -15C/5F weather isn’t a whole lot of fun. But it does give a guy time to think.
So a couple of weeks ago, when I was clearing my driveway, my mind wandered to a piece of advice a software architect had once given me.
We were Wiki before Wiki was cool
Usually the Critical Path is full of great ideas for high-tech project managers and team leaders. We work hard every month to put valuable and practical tips in your inbox.
And that's what we're going to do again next month, and the one after that, and the one after that...
Keep non-developers in the loop
In a perfect world, the specs would always be complete, clear, and perfect the first time, and no client would ever change her mind. Documentation could write their manuals from them. QA could create perfect test plans the first time.
In case you haven't noticed, we don't live in a perfect world. Even the best requirement documents have holes; even the most decided of customers may change her mind about what she wants.