Saturday, March 14, 2009
We've been working on building a consistent, simple process for evaluating and prioritizing requests for IT projects. Historically there seems like there has always been an order of magnitude more projects than there are funds or staffing to tackle. But how to sort through this onslaught of needs to sort out the real priorities?
We've used evaluation matrices for some time to facilitate structured conversations and make decisions about hiring staff and for selecting IT products. The matrices ensure that the information needed to make a decision is complete, and provides the opportunity to capture the relative values of criteria through weights. In poking around the web, I found several processes like this one that use a similar process for reviewing projects. Subsequently we've develop a relatively simple process that looks at both reward and risk associated with a request, and tries to make the scoring as quantitative as possible.
The fascinating part of this is that running a collection of requests through such a tool can be quite enlightening. For example, one of the first things you discover is that often requests are too vague to score accurately, and that they need to be broken down into smaller efforts that start with a feasibility/analysis stage. This helps to explain why prioritizing always seems so hard - it's because in many cases there just isn't good information to make a decision!
You may also discover that small projects with quick turnarounds, small resource needs, and limited risk score well. To a certain extent this makes sense, and lines up well with the principles of good project management.
The most important thing in my mind is that it provides a way to have a thoughtful discussion about priorities - it's critical not to let the tool take over, it needs to facilitate the real issue, which is clear communication.
I spent some time recently mucking with the iPhone SDK. I built this calculator from a tutorial I found after spending a fair amount of time wading through the materials on Apple's Developer site. First, I'm not a coder by any stretch, I have no experience with C, C++, objective C, what little I know is from Basic and Pascal from 20 years ago.
The iPhone is an amazing piece of hardware, and I have even more respect for some of the apps I have running on my phone now that I've been through this process. I typed the code in to get familiar with the editing interface, I managed to find and fix five bugs the compiler caught (mostly typos), however I almost got stumped by a seg fault once the app built and ran. After sleeping on it, I realized I had probably hooked up the code incorrectly in the Interface Builder (the instructions weren't very clear on that part). So I looked at another app that worked, and discovered my mistake.
At this point I can probably create a very simple, relatively static app that provides information (like the first aid apps, for example). But anything beyond that which involves more substantial logic and/or use of some of the cool hardware like accelerometer or GPS would require a lot of training in objective C. My understanding from my reading so far is that managing memory on the iPhone is much more manual than other environments, and can be a major issue if you're not careful about cleaning up. Probably explains why my phone runs better if I reboot it every once in a while.
Apple's desire to control the quality of apps in the Apps Store is understandable - one of the most attractive things about the iPhone is its immediate, consistent usability. Yet it's proving to be difficult to scale. There are something like 25,000 apps in the store now, and the process for getting them approved has slowed down dramatically. Plus there is talk of a Premium Store for apps costing $20 and up. How this will play out as the G1, with its open approach, or the RIM or Microsoft stores get going will be interesting. Support for Flash has long been a sore spot on the iPhone, as it would mean Apple losing control over apps. Yet it would open up the development environment to a much wider market. One thought I've had that might resolve this conflict for Apple is to provide something like HyperCard for the iPhone. I always thought HyperCard was an interesting, multipurpose tool, and it would be great to have that kind of flexible swiss army knife paired with the iPhone hardware.
Friday, March 13, 2009
I got a basic proof of concept multi-touch table built this morning from stuff I scavenged at work (box from Shipping, tracing paper from Engineering, iSight from Desktop Support). It's pretty rough, but does work well enough to demo the principles.
I'm using NUI's tbeta software, they also have a video with the construction directions for the hardware, which took maybe 30 minutes to setup.
It's pretty twitchy, and is very much dependent on the lighting environment. Moderately bright diffuse light seems better than direct bright light.