Skip to content

Moving to Hover

Hover.com LogoSo I recently heard of Hover.com.  It is a Tucows service (and Tucows have been around forever, although I hadn’t really thought of them much in the last decade) and I since I have been doing a lot of work modifying DNS files recently I have come to really loathe the GoDaddy website.  It has been a lot like having to deal with the proverbial used car salesman every time I need to do something with a domain.

Hover’s biggest feature is simply that it doesn’t try to mess with you.  I’ve found all the domain management stuff to be sufficient, although not amazing – but at least it just lets you work instead of screwing around trying to upsell you on things.  Additionally, Hover’s website is nice and clean and refrains from having NASCAR Driver Supermodels offer you AMAZING DEALS on .biz domains.

(Side note:  Don’t ever buy a .biz domain.  You might as well have your domain at .spam.)

My long term thought is that I want to move the various saaspire domains away from GoDaddy where they’re mushed up with domains that I personally own.  But I’ve actually never tried to move a domain from one registrar to another, so I thought I should give it a dry run with something that was real (i.e. not parked) but not mission critical:

This website right here.  Antipatter.

The procedure turns out to be simple.  First you have to “unlock” the domain at the current registrar.  I believe there are restrictions on the unlock (perhaps preventing you from changing registrars just before you have to renew – just when I want to change the most).  Then you need an “authorization code” from the current registrar, and you must give it to the new registrar.

Then you have to make damn sure your administrative contact into is up to date.  Now – here’s a secret:  I didn’t want to pay GoDaddy’s surcharge for not publishing my info, so I’ve given them really stale info to work with.  If you ever have run a WHOIS on any of my domains, well, I haven’t been in any of those places for awhile now.

Hover offers privacy built into their pricing model – there’s no option to NOT have privacy for your WHOIS info.  Note that their one year price is a little higher than GoDaddy’s, but the extra $5 is totally worth it to me.

Once the auth code is provided the request is sent to the current registrar, which then asks permission from whoever is the official administrative contact email recipient.  You reply in the affirmative.

Then they sit on the whole thing for about a week, during which nothing happens.  It reminded me a lot of a bank clearing a check.

In the end the domain transferred and I got a maudlin “Aw, we’re sorry to see you go” message from GoDaddy.  Pretty clean.  I did manage to screw up on not updating my nameservers fast enough, which is why Antipatter (*cough*) went off the air briefly yesterday.  However it wasn’t too painful of a process, so I’ll probably start moving other domains over.

Hover Interface

Posted in business, meta.

No comments

By loren – June 19, 2010

Ecosystems and Organizations

In the past I’ve been in several organizations (businesses, in my case) where management has a sense that something isn’t quite right, and that they have to do something about it.  Often these kinds of problems can manifest in morale, in productivity and in the ability of staff to make good decisions and execute effectively.

Unfortunately, the frequent reaction of management is to attack a particular aspect of the organization, assuming that all of its problems can be addressed in this single space.  They will decide “we need to improve our processes” and focus exclusively on that.  Or maybe they decide that if they can only hire the right people, all of their problems will magically vanish.

The truth is that organizations are powered by an ecosystem of forces that interact with each other.  Good management examines the entire ecosystem, making tweaks (or sometimes wholesale changes) within to address the problem.  Good management knows that there is more than one type of adjustment to make, however.

The Forces at Work

As I mentioned above, a number of forces affect the organization:

People

Organizations, like Soylent Green, are made of people.  The competency, character and societal culture of those people will clearly affect the organization in all sorts of interesting ways.

Generally I divide “people issues” into two categories: the first is what people bring through the door with them – their mannerisms, how they work with others, how they react under stress and so forth.  The second category has to do with how well they fit with their role within the organization.

On the “through the door” side, these issues are well covered by the studies of psychology and sociology.  The best hope is for management to become sensitive to these kinds of issues, and encourage a productive environment.    Frankly, this is an opportunity for strong leadership – management can encourage people to act in a certain way (I’m a proponent of “nice”, for example) by setting the tone themselves.

It should be understood, however, that people’s personalities are what they are – and that they’re unlikely to change for the organization’s sake.   If you can make this work with your organization, great.  If not, well, don’t expect to be able to correct it.  If you can’t live with it, that person probably needs to go.

The role aspect has a fair amount more play.  The essence of employment is that its an agreement by a person (the employee) to fulfill a role defined by the employer.  How well that role is fulfilled is the success of the employment.

Sometimes what is at first glace a problem with a person, is actually a problem with the person’s fit for their role, or the definition of the role itself.  For example, if a role has an unusually high turn-over rate, it may be that there are other issues at stake.  A position that no one can fill is worthless.

Issues in the “role-fit” category can often be addressed by adjusting the role.  This doesn’t have to be negative: sometimes the action is to expand the role – increasing the person’s responsibility.  Sometimes (often) some degree of lateral movement is required.  Often a role organically changes under a person and becomes a poor fit, even though it originally was a good one.

Process

A lot of consultants make a lot of money in this area, because process adjustments are relatively easy to define and execute, at least in comparison to some of the other dimensions in the ecosystem.  Again – process isn’t everything.  It’s one dimension of the organization, and while it can be incredibly powerful as an agent of change, to focus on it in exclusion of the other dimensions is to hold an incomplete understanding of the organization’s health.

Process, or “how we as an organization repeatably do things” is part of the day-to-day structure of the organization.  It intersects with roles, systems (automated or not) and defines the day for many members of the organization.

There are three big ideas to understand about organizational process:

  1. Process has weight: Every procedure, every form, every mandatory meeting and so forth places a little (or in some cases, a lot) of additional load on an organization.  This weight adds up.  Process weight can have the very serious consequence of adding drag to the organization – slowing it down, preventing it from executing on things that are actually important to the business.  This is typically the situation that people describe in large organizations, and is what they seek to escape by fleeing to small organizations.It is important to understand that processes don’t come for free.  Every time a new process is added, the drag on the organization increases.  For this reason, management needs to ask itself if the new process is worth it – are they buying enough of a benefit to justify the drag.  Also, they should question how much drag they are adding, and if there is an alternative that could be implemented in a lighter, more efficient method.
  2. Processes need to be refactored.   No matter how good an idea it seems out the gate, any process can stand to be improved.  (And sometimes replaced, or just scrapped.)  The strongest organizations provide mechanisms by which people who live with the processes on a day-to-day basis can report on how they’re working, and submit ideas for how they can be improved.  Then, the organizations actually act on those suggestions.  ”Dinosaur” organizations occur when the organization is not capable of change – either through lack of willingness or ability to execute a change.  Dinosaur organizations become weaker and weaker over time.
  3. Process requirements change with organization scale: If you are in an organization that is changing size, there’s an additional factor: what worked when you were ten people fails when you are thirty.  What works at thirty fails at 100.  Scaling is the phenomenon of processes breaking repeatedly. If you are in a scaling organization expect process to break more frequently, and that you will need to refactor the way you do things.

Business Quality

Here’s one that often get’s missed: if you are in a bad business – if you are unable to make money (or otherwise succeed in a non-business organization), things are going to be bad no matter how many amazing people or awesome processes you have.  There needs to be a business engine that keeps everything going, or you have nothing.

This third pillar can often be the limitation for many great operational people who know the ins and outs of scaling a business, but don’t operate well at the actual layer of the business itself.  Why does it work?  The business model, the marketing, the various outward-facing ingredients that determine the success or failure of the organization in the marketplace, these simply cannot be ignored when thinking of the overall health of the organization.

As a personal example, I spent a while trying to build a startup focussed on the music industry at the exact same time the music industry was going through its existential collapse. (From Napster to iTunes, basically).  I had tons of great ideas for how to scale the business from a personnel and process perspective, but the underlying quality of the business wasn’t strong enough to support it.  So it didn’t work out.

Leadership and Culture

The final two dimensions are less of pillars and more of the medium through which quality spreads through an organization.  You can think of them as magnetic poles, because they interact with each other and make things happen.

Leadership comes from the people at the top: the founders or top management.  Leadership obviously defines a great amount of strategic and executional aspects of an organization, but additionally, leadership defines the original culture of a company (often subconsciously).

Over time, through hiring and firing practices, and internal interactions, leadership creates the culture of the company.  If leadership acts unethically, it will become part of the company culture that unethical behavior is acceptable, and in turn the company will attract unethical people.  For all aspects of culture this is true: drama begats drama, creativity begats creativity, hostility begats hostility and so forth.

In a future post I’ll start having a look at treating organizational issues in a holistic manner, by applying this model to understand where problems intersect, instead of approaching issues exclusively from a single dimension.


Posted in business, management.

No comments

By loren – June 12, 2010

Siloing (A Rant)

Recently, I’ve noticed that what I originally remember as “folks who make websites” has grown and specialized into a bunch of different jobs.  Jobs held by people who are not necessarily watching how the decisions they make affect other parts of a project.

Not to be overly simplistic, but there are three basic perspectives of web development:

  • Usability, or user experience.  In its broadest definition, this is a measure of how good the web app is to the user; how much value it creates for them.  In a more specific sense it reflects a stack of best practices (and very, very occasionally innovations) that add up to the user experience on the site.
  • Business value.  In the broadest sense this is “what the web app is doing for the people who pay its bills”.  This can be interpreted as monetization (via ads, conversion etc), or simply controlling the budget and schedule of the development project.
  • Feasibility:  Often taken as a technical subject, it its broadest sense, feasibility simply describes how much effort goes into making something happen.

The catch is, to truly make something successful, both from the perspectives of  project management (launch on time, on budget) and product management (build something that is successful in the real world), you need to keep your eye on the ball for all three perspectives.  Otherwise you’ve failed.

For example, I’ve seen user experience people run wild with feature ideas, not paying attention to the development cost that such features incur.  I’ve seen the opposite as well – web apps with terrible user experiences that are vulnerable to losing market share to better designed products.

I’ve seen project sponsors focus on business value at the expense of user value, and then are surprised when no one uses their product.  I’ve seen projects that have been managed perfectly for schedule and budget (perfect scores to the project manager) fail in the open marketplace because they didn’t bring value.

Which Brings Me to the Siloing Part…

So to really succeed, you need to synthesize all three perspectives into a unified vision.  That’s why it drives me crazy to see so many people in web development so oblivious and willfully ignorant of perspectives other than their “native” perspective.  UX people that make features up without understanding development cost.  Developers that launch features without considering a usable interface.  PMs that manage schedule and budget without comprehending the quality of what they’re developing.

Do you really want to be good at this?  Then learn about the perspectives that are different from what you deal with every day.  UX people should understand the constraints (and advantages) that technology puts on development.  Developers should appreciate the business goals and usability issues related to the products they develop, and PMs should understand the vision of the products they’re managing.

Process is Not The Answer

Process alone, especially any process that involves creation of a bunch of intermediate documents or getting people to show up for a bunch of meetings, is not going to fix this.  The people who work on web applications need to internalize the other perspectives, and make it their personal responsibility to understand this.

Once this happens, an organization can support people by offering pathways to education (courses, books, conferences etc), but the people need to personally commit.

Admittedly this makes a barrier to scaling, because not everyone is interested in other perspectives.  They got into their own discipline (development, project management, visual design, UX etc) for a reason, and that’s where they want to stay.

My view is that the willingness to see the other perspectives is what separate the truly talented from the mediocre, and the mediocre will not be working for me any time soon.

Posted in business, web agency.

Tagged with , , .

No comments

By loren – March 21, 2010

It’s a Remote Control

In about 2 weeks Apple may or may not announce a product that may or may not be called the iSlate, or iPad, or iTablet or whatever.  Speculation is currently absolutely rampant across the digirati.  Some say it it will be an e-reader, some say a big iPod, some say a netbook Mac.

I’m going to go out on a limb: it’s the ultimate remote control.

This is entering the age of networked hardware.  The “internet fridge” concept that nose-dived 10 years ago is back with a vengeance: hardware will be on the net, addresses web services.  Cars, appliances, strange boxes that you connect to your TV and home – all of these need user interfaces.

However, UI’s are both expensive to build, and frankly hard to pull off well.  That’s why we’ve seen generation after generation of terrible UI’s from hardware manufacturers – each being forced to reinvent the wheel over and over.

But now – why bother?  Apple creates tools to build pretty good application UI’s without an overwhelming amount of work – and a streamlined mechanism (the iTunes app store) to distribute them.  So instead of sinking a lot of cost into developing your own complete user interface for your hardware – why not just hook up to an app on a device that the user already owns?

There are already examples of this in the wild: the ZipCar iTunes app will actually unlock your car.  If you invest in a Sonos sound system, you can run it from an iPhone app.  And apparently the Ford Sync system is slated to run apps that you’ll be able to buy from the iTunes store.

So what might be possible if you had a 10-inch device that could act as a remote?  Run a gigantic entertainment system?  Dock in any piece of hardware and become a touch screen control for it?  How about I use an “iSlate” to start my car?  A $700 device isn’t that much against a $20,000 car.  Or – how about running your home?  AC, Heating, security etc could all be run from the iWhatever.

Using the standard user interface SDK and guidelines, people build controls for hardware based on behavior that is already well understood.  The learning curve is reduced, and companies don’t have to sink a lot of money into UI development for their devices.  It’s a slam dunk.

Posted in Uncategorized.

No comments

By loren – January 17, 2010

I.T. Organizations Considered Harmful

Okay, this post is going to be a big shot across the bow, and for that reason I’ve waited a bit to post it – in order to try to get my thoughts together.

Having spend the last 4 years or so working in web agencies, I’ve seen the inner workings of the IT department in many, many companies – from mom and pop operations to Fortune 500 outfits. More often than not, the IT department is really, really broken.

First, let’s have a look at what broken means:

Symptoms

Lack of Prioritization

Faced with conflicting demands from different business units, the IT group is unable to plan where to spend its energy, and so lives constantly in a reactive state, servicing whatever the squeakiest wheel happens to be at any given moment. Essentially it’s locked into a state of putting out fires, and is unable to put energy into actually making things better.

Often this can be a result of lack of “informed power” regarding the IT department: senior management doesn’t really have the understanding to view IT as an allocatable asset, and no one in IT has the power to push back on the immediacy of the next business stakeholder’s fire – regardless of whether it’s important to the business or not.

Lack of Bandwidth

Related to the prioritization issue, but slightly different, is the fact that most IT organizations simply don’t have enough people to do the volume of IT work demanded by the organization. At the same time, however, there is resistance to hiring in IT, because IT is viewed as a pure cost center in most organizations. In other words, it is not viewed as a vehicle through which the organization can make money, but rather just a place where spending occurs. In an environment of cutbacks, it will be trimmed.

Communication Problems

Often business stakeholders and IT just can’t understand what the hell each other is saying. Business users generally have a sense that certain features are vastly more important than others, but don’t always communicate this prioritization if they’re not asked. Additionally they may jump immediately to a specific feature implementation (that may be taken as a requirement by IT) that isn’t really what is best for them. Business stakeholders are not going to have any sense of feasibility, however: they don’t know how hard it’s going to be to do things.

IT comes from the opposite end. They understand feasibility, but not business importance. Unfortunately IT has the habit of taking all “requirements” from business as of equal importance, and just plugging away, looking at things purely from a feasibility perspective. When combined with the business stakeholder’s habit of proscribing features instead of just stating needs, it can lead to a lot of wasted effort.

Fortress Mentality

When things go wrong with technology, who get’s blamed? IT. When things go right, who get’s credit? No one.

In a sane business decision, one weighs the upside against the risk. There are many cases where it’s worth it to take a risk in order to achieve a big payoff. But IT is essentially balancing risk against an upside of zero. Naturally, that means they will seek risk avoidance in every case. This minimizes the chances of things going wrong, but it also minimizes benefits that might be had from technology.

Consequences

These symptoms turn an organization’s interactions with their own IT group into a big, dysfunctional dance. Business stakeholders feel that IT is unresponsive, slow to complete projects, incomprehensible and too restrictive. They start to come to the blanket judgment that IT is not going to be a solution for their problems.

IT for their part, feels under-appreciated, constantly putting out fires, under-staffed and forever dealing with clueless users. They have ideas for how to make things better, but never have time to implement them. On the projects that they do get to work on, they’re shocked to find out that features they’ve worked so hard to implement are being unused by business stakeholders.

This dysfunction has even led to a culture of circumventing IT. Business stakeholders (as much as they might like to) realize that they simply cannot live without having certain technology services performed, but feel that IT will be unable to help them. At this point they may look for outside help – either from product vendors that claim to “do it all”, to agencies that usually make the same claim.

The product vendors or agencies may be just fine, but that doesn’t change the fact that the organization has chosen to outsource a part of its business, not on the basis that it isn’t core to their enterprise, but rather on the basis that they are incompetent to execute. Since IT work is often the automation of a core business process, outsourcing it can lead to a weaker overall organization.

So there’s a picture that’s probably familiar to many. How do we fix it though?

How to Fix IT

Fix the Accounting

If technology has benefit to an organization, then that benefit needs to be reflected in the way the organization accounts for itself. From a financial perspective, a business will look at the profitability of its various components (at various levels of formality, depending on the size of the business) and make decisions about where to invest.

Businesses need to stop looking at IT as pure cost centers. That means that the credit for adding value to business units needs to find it’s way back to IT somehow, and be measured against IT costs. Here’s two possible ways to do that:

Charge the Business Users

If business stakeholders use IT services, they have to pay for them. That way the “cost of IT” lands squarely on the business stakeholders that use IT services. Of course, the side effect of this is that the quality of what the business users are paying for will immediately fall under scrutiny, but that’s okay. The point is to make the organization stronger.

Credit IT with Results

Let’s say IT builds a system for a business group, and as a result there is a reduction of cost for that business group (or even better, a measurable increase in revenue). Some of that savings/earnings increase should again be credited back to the IT department, and shown as income (or something equivalent). Again the political side of this action will be determining how much credit to kick back to IT. Too much would additionally have the negative side effect of making the business groups less interested in such activities, as they aren’t being credited with the results.

Hire Technology Leadership

Particularly aimed at the communication / prioritization issues, the solution is to hire a senior person with a technology background who:

Can Translate: Someone who can speak the feasibility-heavy language of developers, and the priority-heavy language of business stakeholders. Someone who knows when to ask context-breaking questions, such as identifying the real business issues instead of just accepting prematurely prescribed solutions dictated by business stakeholders.

Can Design Solutions: Someone who can take the real business requirements and come up with a technology-based solution, then take that solution and articulate it as technical requirements for the IT Staff. This is an individual who understands both technology and business.

Has Authority: This person needs to be able to push back. It is inevitable that forces within the organization will attempt to mis-use IT, either pre-selecting the wrong solution, or by short-circuiting the priorities of the IT group. The Tech Lead has to be able to say no to those forces, and find a real solution that balances the real needs of the business stakeholders within the larger context of the organization.

Decompose IT

The most radical step is to send IT staff out into the wilds of business stakeholders. Instead of a common pool of IT resources, an organization could choose to send, for example, a technical PM, a couple of developers and a sysadmin out to exclusively work on the problems of a particular business group.

This is an approach that probably makes the most sense when the needs of a business group grow beyond a certain point. At that point using centralized IT resources becomes less effective than maintaining their own technical staff. The obvious concern is that efficiencies of scale are lost when technical resources are distributed amongst business groups, but this is a good choice when the effectiveness of those resources within the individual business groups makes up for any loss from decentralization.

The upside to decentralization is that the accounting problems just go away. The efforts and results of these distributed staff are just measured within the individual business group, who will either be able to justify the expense or not, on the same kind of merits that they use for everything else.

It is important in these cases that technology leadership/management is included in the distribution, or the business units can find themselves saddled with a lot of the communication issues mentioned above. Because of this, this is a significant and potentially expensive step for a business group.

Conclusion

IT in most organizations is broken – it’s not providing the kind of support and advantages to business users that it could, and is the source of frustration and feelings of helplessness for many employees, both business and tech. By re-structuring the way IT fits into organizations, it can deliver on it promise at last.

Posted in business, tech strategy.

Tagged with .

1 comment

By loren – August 23, 2009

Modeling Risk (Part 4) – Putting It All Together

In this, the final installment of the Modeling Risk series, we going to put together everything we covered in the previous installments into a unified risk model.

risk

In part one we learned about Client Risk: risk that clients bring when they walk through the door.  Based on attributes such as the ability to make decisions, relative insensitivity to price and technology agnosticism, clients can either be part of the problem or part of the solution when it comes to managing risk.

In part two we learned about Structural Risk: risk that is derived from how the team is structured – whether they are familiar with each other, a common process, the tech or the client.  In some ways this type of risk is learning curve risk, because it models how many learning curves are piled onto the project.

Finally, in part three we learned about Qualitative Risk: risk that is driven from the quality of the team, the technology and the support for the team.  The better these things are, the more curve balls they can handle, and the more they can cope with risk from the other vectors.

From each of these three aspects of risk we derived an overall letter grade: from A to F.

Putting it All Together

Here’s how the letter grades combine:

Low Risk: All A’s and B’s

This is a good to great project with minimal risk.  In this range you can count on projects staying on track, and arriving where they are supposed to within budget, on schedule and at a level of quality that will satisfy everyone.

Medium Risk: One or Two C’s

This is a project that has a combination of a relatively problematic client, an immature team, or mediocre quality issues.  It is possible to succeed in this space, but it requires a close watch and quick action to mitigate the problems that inevitably will come up.  The success of the project depends on at least on of the three areas being better than the “C” level – the strength that can hold up the project.

High Risk: Three C’s or One or Two D’s

This is a project that, from its onset, has a good chance of going bad.  Either there is no strong area that pulls the project up to the medium risk level, or there is one or more areas with real problems: a truly high risk client, an immature team or poor quality from the team, the technology or the team’s support system.

Despite the best risk-mitigating activity from management, there is still a good chance that this project will go wrong.  It would be  a sound decision to walk away from such a project, but if taking it on is necessary, then it should be approached extremely defensively, as there will inevitably be serious crises as the project progresses.

Lead Balloon: One or more F’s, or 3 D’s

This is either a project with an impossible client, a disastrous team, or a catastrophic quality issue; or it is a project that is merely poor in all three areas.

Generally speaking, it is not possible to be successful with such a project.  The presence of the F will sink the project on its own, or the general malaise of the 3 D’s will accumulate into a disaster.

A project at this level needs a fundamental reset: generally either the client or the team has to go, depending on the source of the problems.  Risk mitigation at this level will be overwhelmed.

Conclusion

So there you go – my general theory of project risk.  I hope that you find it helpful, and through it gain a greater understanding of why projects succeed and fail, and when to plunge ahead, and when to run the other way.  Good luck!

Posted in business, programming, web agency.

Tagged with .

No comments

By loren – August 19, 2009

Modeling Risk (Part 3): Quality

The plot so far:  there are specific things that cause project’s to fail, beyond the abilities of seemingly competent people to control.  These forces aren’t random, they are specific patterns and antipatterns that create accumulating risk that bears down on projects like debt.

In Part 1 we discussed client driven risk – the problems that clients bring to the table and how they affect the project.  In Part 2 we discussed structural risk – risk that originates with the composition of the team working on the project.

The third and list type of risk I call Qualitative Risk.  This is a kind of risk that is affected by the quality of the tools and people executing the project.  Everything counts, everything matters.  Quality affects the project.

There is a school of thought in business that would dearly like to factor quality out of the equation.  Businesses that trade in commoditized markets, competing on price, basically operate on the supposition that there is a standard level of quality and that it is not a distinguishing characteristic.  The movement towards off-shoring software development included an attempt to factor out quality.  Command-and-control programming languages like Java and .NET are attempts to engineer developer quality out of the equation – at least partially.

Quality, however, matters.  The web development framework you choose will affect the project, positively or negatively.  The skills of the developers you hire will affect the project.  It is not just subjective, some of these things are actually better than others.

I break Quality factors down into 3 main pillars: Team, Tech and Support.

Team: How strong is the team?  My feeling is there should be at least 1 really good senior developer for every 3 medium or junior developers on staff.  In addition, it is good to have at least a couple of honest-to-goodness rock stars around – the people who can be thrown against any technical challenge and still land on their feet.  The bar should be set at a level where the team can be counted on to astonish you on at least a semi-regular basis.

Tech: How good is the tech on which you’re building this thing?  Does it provide features that you need?  Does it provide a means of accelerating custom development, in case you need to go outside those features?  How often is time spent using the technology solving actual business problems, as opposed to just servicing the demanded ceremonies of the technology?  When is the technology enabling you, and when are you fighting it?

Support: The infrastructure: managerial, administrative, legal, HR etc., that surrounds the team – how much is it helping?  Is HR effective in finding new talent?  How about support from IT?  Is it straightforward to get ticket systems, continuous integration servers, new virtual servers etc. set up?  Or does every request take forever, with the development team resorting to circumventing the company infrastructure?  Does management back and support the development team, or are they selling them up the river?

Each of these pillars is deep and complicated, so grading them is a little abstract.  However if you set an aggregate grade for each pillar and take the average you’ll get a sense of the qualitative risk associated with the project.  Again, starting about the C grade and intensifying as you drop below that, you can easily get to a level of unacceptable risk.

In the next and final installment of this series – we’ll look at putting all the various risk factors, client-driven, structural and qualitative, into an overall risk profile.

Posted in programming, web agency.

No comments

By loren – August 6, 2009

Modeling Risk (Part 2)

In part one we had a look at risk that comes to the project from the client, before it even starts.  This time we’ll look at risk that comes from the composition of the project and the project team.

I like to call this second category Structural Risk, because it has to do with how a project is structured: the parts that make it up.  Again, to take the positive angle – each point below is listed in its non-risk-adding, positive side:

  • The team has worked together before. The team itself is a known quantity, with the individual talents and personalities of each team member known to the group.  This knowledge allows team members to guide the project to leverage the various strengths and avoid the weaknesses of the individuals on the team, working together to achieve the highest level of productivity.  Also hopefully people like and respect each other.
  • The team knows the technology. It is a technology that the team has worked with before – they know how to work with it rather than wind up fighting it.  They are unlikely to be surprised by strange quirks of the tech stack that creep up at the most inopportune times.
  • The team knows the client. The team has worked with this client before, and therefore knows the business problems that intersect their space.  This way they will be less likely to make poor assumptions about how things are supposed to work.  Functional specs are great, but they don’t take the place of actual domain knowledge on the part of the team.
  • The team has a methodology for staying on track. Without getting into the comparative merits of individual development methodologies, the main point is that the team has a way to prioritize, track progress, and correct problems early on.  A team that can’t tell that it’s off-course can’t correct.
  • The team can effectively communicate to management, and vice-versa. The cliche is that management understands different levels of priority for requirements, but sees all cost of implementation as equal.  Developers see different costs of implementation, but imagine all requirements to be equally important.  Neither is true, of course, and there needs to be an effective channel for technical and business stakeholders to properly communicate with each other.  A Tech Lead can be an effective method here.

Note that none of this discusses the individual experience or quality of the members of the team.  This is structural.  Process and management – all about getting people to speak with each other, and work well together.

Again 1 point for each “yes” answer for your team, just like in part one.

5 points: A. Your team knows each other, the client and the means to success like the back of their hand.  You’ve probably already made the mistakes you are going to make, so you can count on solid execution from people.

4 points: B. Still solid.  B is as good as a team can get with a new client (and at least in agency work new clients are frequent).  B is structurally still a good risk, but can occasionally throw up a surprise or two.

3 points: C. Medium risk.  At this level there is at least some degree of immaturity in the team – it may reflect new hires, or the creation of a new team where there wasn’t one before.  The team is still working out the kinks in their process.

2 points: D. This is an immature team.  There are enough unknowns going on at this level that the team can easily trip over itself, adding significant risk to a project.  Watch out.

1 and below: F. The team is not ready for this project.  The structural problems will create a significant negative impact on the project, probably leading to some level of failure.

To be concluded in part 3, where we’ll look at qualitative risk, and how to combine all the risk factors together into a single model.

Posted in business, programming, web agency.

Tagged with , .

No comments

By loren – August 1, 2009

Modeling Risk

Why do some software / web projects run off the rails so badly?  Are we just incompetent?  Is it that the very practice of programming is so incredibly difficult that it defies any attempt to manage it?  Perhaps software development is just an inherently terrible idea, and we should leave it up to Microsoft to handle, and focus on other things, such as selecting the best clip-art for our PowerPoint slides.

Okay, no one buys that exactly, but there is a certain amount of seeming randomness in software or web development that makes developers and managers both very, very nervous when entering new endeavors.  Everyone knows from past experience that even with the best of intentions, things seem to occasionally go terribly wrong.

I’d like to suggest that things happen for a reason, however.  In the case of software development projects, there are specific patterns and phenomena that drive projects towards success or failure, and that learning to recognize those patterns can lead one to manage them much better.

In fact I would take that one step further, and say that these patterns can actually be modeled, and together form a bit of a magic 8-ball on what’s likely to happen with the project.

Clients

Many software development projects have clients involved, and for many of them the problems start right there.  Clients present an extremely powerful influence over projects, because if they are not happy, there is no business.  Clients do not always act in their own best interests however, or the best interests for the project.  Therein lies the rub.

I’ve identified a specific set of criteria that identifies good clients.  Clients with these attributes are good, those without them are bad.  Howe much risk a client brings to a project depends on how many items on this list they rate.

  • Strong decision maker: Is there someone (much preferably an individual person) who can make decisions in the client organization?  Or is there a distributed set of stakeholders, all with different agendas, values and visions about what the product should be?
  • Reasonably Insensitive to Price: Does the client appreciate the value of what they’re getting?  Or do they just want to slash, slash, slash prices and get the cheapest possible version of their site?  Do they argue over every last nickle and dime?
  • Technology Agnostic: Tech matters.  Anyone who says differently is ignorant or lying.  The choices of hosting, frameworks, platforms, products etc all compound and add or remove risk from the project.  Good clients are ones that allow and encourage the best tools for the jobs to be used.  Bad clients come in the door with corporate technology mandates that have nothing to do with the specific interests of the project.
  • On a Reasonable Deadline, but Flexible on Scope: Projects need schedules in order to happen, but the uncertainty baked into programming demands that something in the classic project management triangle flex, and the best thing to flex is scope.  When there is a clearly prioritized set of features on the table, the upcoming release may or may not have certain features, or they may be implemented at a number of different levels of complexity.  Hard features of limited business or user value should be jettisoned.
  • Savvy: Good clients know their own business, the Internet and so forth.  Clients that require teaching on every last point that intersects the project slows things down, and opens the door for them to make bad decisions.  A client that is reasonably well educated on their space and how it relates to the project will be much less off than others.
Grading

For your client, award 1 point for each of the above criteria.

5 points: A. Run, don’t walk and get this client’s business.  They are extremely rare and can be the basis of an excellent partnership in which you can do great things.

4 points: B. A good, run of the mill client.  Will occasionally do something bothersome, but well within the parameters of something that can be managed for success.

3 points: C. Fair.  This is starting to get into the range where client risk can adversely affect the project.  If it is combined from risk from other factors, failure can occur.  Nonetheless it is possible to succeed with a C client.

2 points: D. Not good.  This is a high-risk client, and this kind of work should only be taken on if painstaking steps are taken to protect the team from bad influences and decisions made by the client.  A large amount of time will be spent on keeping this client under control, and preventing them from damaging the project.  It better be worth it.

1 and below: F. This client brings disaster with them.  It is almost impossible to succeed with this kind of client, and it usually isn’t worth it.  They will be a never-ending source of problems, and will compel bad decisions that will most likely derail the project.  Avoid.

Continued in part 2, when we’ll look at some of the other risk factors that bear on a project.

UPDATE: Okay, so I covered some of this before, but this is part of the model, so its sort of from the opposite tack.

Posted in business, programming, web agency.

Tagged with , .

No comments

By loren – July 25, 2009

Obligatory Whining About Not Posting

Yes, this is my blog. No, nothing has happened here for some time.

About 11 months ago I became the Director of Technology for HUGE. This took a lot of my brainpower over, and the most immediate casualty was Antipatter. Mea culpa.

I’ve made fun of well meaning friends who have, in the past, spent a lot of time developing their own blog software, but haven’t really posted much. Of course they are now kicking my butt.
Then I became tired of the brown theme, and have spent too much time screwing around with the look and feel. That needs to change, but not at the expense of posting.

Finally, Twitter enables laziness in blogging on my part. Instead of developing an idea enough to blog it, it’s really easy for me to knock out 3 or 4 tweets that capture the barebones essence of my point. This is just lame.

So while I can’t really promise a particular frequency of posting here, I will do my best to put something up once in awhile. I’ve certainly had thoughts that could have gone up here in the last year, it’s just a matter of capturing them and getting them posted.

Posted in meta.

No comments

By loren – July 18, 2009