OpenSourcery to build new online habitat for The Oregon Zoo

Noah Kleiman — Wed, 09 Nov 2011 20:12:55 +0000

OpenSourcery is pleased to partner with The Oregon Zoo as we work to build a new “elephant strength” Drupal website for the oldest Zoo west of the Mississippi. 2012 marks the 50th birthday of Packy, the oldest male Asian elephant in the United States, and the 125th anniversary of the The Oregon Zoo. The Oregon Zoo welcomes more than 1.6 million visitors each year and is recognized worldwide for it's successful elephant breeding program.

Inspiration from my first BADCamp

Adam DiCarlo — Tue, 01 Nov 2011 23:09:20 +0000

I recently had the pleasure of attending my first Bay Area Drupal Camp, and enjoying some oddly-sunny late October days in Berkeley, CA. Rather than touch lightly on all my favorite BADCamp moments, I'd like to concentrate on two of the topics that inspired me: the Advanced Theming session and Beans.

"Advanced Theming" session with Tim Cosgrove

Tim shared how to use a grid system and the Block Reference module to essentially implement a much simpler version of Panels. The Block Reference module provides a field that can be used to reference blocks in a node, and thus embed the block's content in the node display. Tim showed a content type with three block reference fields that are assigned grid classes; this allowed him to quickly construct a node type that displays present three columns of listings beneath the node's body content. In order to keep theming work consistent, Tim suggested using Views's Content row display format rather than the Fields format. The Content display format lets you choose which view mode. The view modes that come with Drupal don't provide enough different ways for you to format content (Default and Teaser), but you can create new view modes using code or using the Display Suite module. So you might end up with view modes like "Title only," "Title and teaser," "Thumbnail and title," "Thumbnail only," etc. For sites with similar enough content types, defining these view modes gives site editors a lot of flexibility; especially when you allow them to select which view mode to use when creating a new listing block. So how can we empower site editors to make use of these view modes without throwing them into the deep end of the Views ocean? Beans are the answer!

Beans, beans, beans

Beans are a new way of creating blocks. Beans are entities, so, like with nodes and content types, you can create different block types and add fields to those block types. Bean types can also use custom plugins; bean plugins use custom code to create a configuration form for the block type and generate the block's output. A great example use is for creating configurable listing blocks that site editors can readily add to pages. Rather than building out exactly the blocks you planned on and wireframed, you use Beans to build a blocksystem that the client can use with some flexibility; for example, let's say that two pages on the site need a "Featured Content" views block. One displays the latest 5 Articles, the other displays the latest 3 Products. But, weeks after the site goes live, the site editor wants to add a "Featured Content" block in the same format, but wants it to display the latest 2 Widgets instead. If you built the Featured Content function with normal Views blocks, the site editor would need to go into the Views UI and create a new Views block display on the Featured Content view. For a non-professional Drupal user, this is dangerous and tricky. However, if you built a custom "Featured Content" block type that is configurable (it lists the latest [X] entries of content type [Y] using view mode [Z]), then the site editor is in luck! They can simply create a new "Featured Content" block and configure the new block to do what they want. That's easierand safer.

So those were my two main sources of inspiration from my first BADCamp. I'm already incorporating Beans (with a couple of custom bean types) into a new Drupal 7 site we're building, and am looking forward to using Block Reference the next time a project calls for a lightweight block layout method. These are very powerful tools that can give clients lots of flexibility without adding lots of complexity. This is the perfect example of what I love about the Drupal community -- each gathering is like connecting to a hive mind with new ideas that not only end up improving the sites we build, but that keep working with Drupal fresh and exciting.

Playing Ball part 6: Signs that the deal is already done

Noah Kleiman — Tue, 20 Sep 2011 18:18:56 +0000

It's not uncommon for seemingly open RFPs to be issued in cases where the winning bidder has been preselected.

Why are “done deal” RFPs created in the first place ?

People at a company have a project that needs doing. The People decide to work with trusted contractors they know or have worked with in the past. They might even get as far as brokering a verbal agreement, when someone at the company realizes they have to follow the procurement policy. The policy usually says that contracts with budgets over a certain size must be put out to bid. Sometimes review of a minimum number of competitive bids is also stipulated. A very thorough & official-looking RFP is issued, as a formality, and the end result is people work with the folks they know.

Of course you aren't planning to do this, so why does this matter to you ?

If you don't have a lot of experience writing RFPs it's not uncommon to use example RFPs as a guide.Organizations which have a policy which requires RFPs often have a very refined template for generating RFPs. This means there are lots of easy to find examples of very good looking “done deal” RFPs. If you don't know how to spot a “done deal” RFP you might unintentionally use one as the model for writing an honest and open RFP.

Experienced web developers are pretty good at spotting a “done deal” RFP and won't waste time preparing a response. If you base your RFP on a “done deal” RFP you risk driving away the most experienced potential bidders.

Is this a done deal ?

RFPs which use vendor-specific buzz words or non-standard industry terms in the requirements suggest that a specific vendor was involved in drafting those requirements.

A very short response deadline is a dead giveaway that the person writing the RFP doesn't want additional proposals to review. Less than 3 weeks is questionable, a week or less is a red flag.

Unreasonable or strangely specific experience requirements might indicate that the RFP writer already has a proposal in hand from a preselected developer who meets these requirements. For example: Please provide 5 or more examples of websites you've built for other State Universities, At least 5 years experience integrating websites with our internal EsOhTerriK ™ database, etc.

A very detailed implementation timeline can indicate the RFP is a done deal. It's ok to specify when the proposal is due and when the job needs to be done, but it's usually left up to developers to determine the implementation schedule and milestones for the project build. Including dates for minor development milestones in your RFP is a signal that you've already got a proposed timeline from a developer.

2011 Pacific Northwest Drupal Summit

Noah Kleiman — Fri, 16 Sep 2011 21:04:44 +0000

OpenSourcery is proud to be a Gold Sponsor of the 2011 Pacific Northwest Drupal Summit

At OpenSourcery we're committed to building a thriving habitat for Drupal developers in the Pacific Northwest. That's why we're proud to support the 2011 Pacific Northwest Drupal Summit at the highest sponsorship level. The Pacific Northwest Drupal Summit is a gathering for Drupal professionals to expand their coding skills and connect with other Drupalers.

OpenSourcery staff have volunteered for months to help organize the event and several of our team members submitted proposals for sessions at this year's Summit. We're pleased at the turnout, tickets for The Summit are sold out.

Thanks to all the volunteers, event sponsors, and attendees for your part in raising this year's Drupal Summit to new heights. Hope to see you there.

Playing Ball part 5: Meet Your Internet Neighbors

Noah Kleiman — Tue, 06 Sep 2011 18:02:41 +0000

In an effort to minimize web development project risk, RFP writers sometimes place strict requirements on the geographic location of responding firms. For example, a nonprofit agency in a small town might state in an RFP for their new website that the web developer needs to be able to meet in person at their office throughout the project.

This has the effect of reducing the number of well qualified responses to the RFP. The best web developers can't afford to move to your town for a 3 – 6 month contract. Well established firms are used to collaborating with clients via web and video conferences.

Proximity doesn't ensure accountability, though it does increase the chances that you'll bump into your web developer at the supermarket.

In terms of collaboration, time zones mean more than geographic co-location. If two groups are in the same time zone then they are next-door Internet neighbors. If you're within 4 hours of each other, you can work together comfortably with no problems, you're Internet neighbors.

Feel free to work the geographic flexibility of the Internet to your advantage. Spend that Manhattan money in Portland, Oregon where the overhead is lower.

Playing Ball part 4: toss the ball easy, to start

Noah Kleiman — Thu, 25 Aug 2011 16:30:49 +0000

When writing a RFP for web development services, focus on making it easy for folks to initially respond with a proposal. Remember most review processes take place in two stages; a “first cut” review and a follow-up interview process with two or three selected bidders.

Scrutiny happens in the second phase, not the first. So keep it simple in the beginning. Don't ask too many questions. You might consider holding off on requesting client references until after you have identified your top three candidates. You should be able to get the background you need in about 10 – 15 basic questions. One of them can be “tell us about your background and experience”. Don't ask questions which aren't related to the business of web development. Developers don't want to discuss their favorite T.V. shows (or your favorite T.V. show), for example.

Developers who know they are on the short list for your project will be much more willing to answer questions, provide client references, etc.

Playing Ball part 3: Are we playing ball in the same ballpark ?

Noah Kleiman — Mon, 15 Aug 2011 18:54:51 +0000

Include a ballpark budget range in your web development RFP. Leave out this critical piece and the most reliable developers won't respond to your request. Keep in mind the budget you tell contractors needs to reflect what you can actually afford to spend on your website.

Having a budget discussion early in the process helps to ensure that both the client and the contractor are in the same league and playing in the same ballpark. It's only worthwhile to toss the ball back if the developers have some assurance the potential client will be able to catch it.

There are a number of reasons folk might be hesitant to include a target budget when requesting a price quote. They might be unsure about what a reasonable project budget range is, or concerned about the impact a stated budget will have on the price quote. If you're nervous about this too, let's take a moment to look at what actually happens in some different situations.

These examples all assume that you're dealing with a reputable contractor, whom you can trust; As a general rule, we advise against hiring contractors you don't trust.

Situation #1
A potential client asks for lots of bells and whistles and provides a target budget that is substantial, but far too little for the scope of work requested.

Detailed estimations doesn't move forward until the scope is reduced or the budget is increased. The goal is to figure out some way to deliver what client #1 actually needs given the resources at hand, if that's at all possible. A phased approach to development might be suggested.

Situation #2
A potential client asks for some very fancy features and the stated budget turns out to be substantially greater than it needs to be.

The estimations and proposal process moves forward smoothly. Engineering findings and costs are provided in a transparent format so that potential client #2 can see the basis of the quote. From the contractors perspective we're excited to deliver the news that the project will cost less than expected, since this means our bid will be competitive. Assuming client #2 accepts the bid they don't end up spending more for having provided a greater budget.

Situation #3
A potential client asks for very simple features and the stated budget is also very small.

Some projects are too small, or too simple for our firm to do. Letting us know the target budget in this case would result in getting a referral to reliable freelancers who specialize in smaller projects.

Situation #4
A potential client requests a quote and provides us with a firm budget limit just a wee bit lower than seems feasible.

If an estimation is expected to come out over a firm limit, we might reach out to the potential client to determine if there is some wiggle room in the budget or to suggest some strategic adjustments to the scope of work.

Situation #5
A potential client needs advice about what a reasonable budget range is for a scope of work.

It's perfectly ok to ask a reputable development firm for advice about an appropriate ballpark budget for a web development project. Do this before you solicit proposals to make sure your organization has the resources needed for the project.

Playing Ball part 2: It's About Time

Noah Kleiman — Mon, 08 Aug 2011 17:46:25 +0000

In the previous article I covered the problem of risk in web development projects. There is a mix of experienced and inexperienced developers, and sometimes it's hard to tell them apart when reviewing RFP responses.

Of course you'll never be able to tell them apart if you only receive responses from inexperienced developers. Before we tackle telling the alfalfa sprouts from the redwoods let's look at a simple step you can take to help ensure that experienced developers respond to your RFP.

The very first thing I look at when evaluating an RFP is the deadline for the proposal. Have the people issuing this request provided enough time for a qualified firm to respond ?

Keep in mind responding to an RFP means the developers clarify the technical requirements, create an implementation plan and estimate the time required to do what needs doing. If the request for proposal doesn't provide a few weeks (minimum 2-3 weeks from when potential bidders first see the RFP) to respond, then you'll only get proposals from inexperienced developers.

This is how the element of risk first enters the picture. When too little time is alloted to provide an estimate based on engineering findings there are some natural consequences. Inexperienced developers will try to make a quick guess at the cost for building your project and experienced developers won't respond at all.

Web development projects that start off this way frequently spiral out of control in the final weeks or months of the project. In the worst cases an inexperienced developer will start to feel saddled by the project as the number of hours spent on the project exceed the guesstimated project budget. “We've been having trouble getting our developer on the phone” is a common symptom with cases like this.

A little planning time in the proposal stage really goes a long way toward bringing your project in on time and on target.

Playing Ball: simple playground wisdom for writing a successful web development RFP

Noah Kleiman — Thu, 04 Aug 2011 22:27:27 +0000

OpenSourcery's Nonprofit Ambassador shares the story behind how experienced web developers review a request for proposals.

Part 1: The Problem of Risk

Web application development is a totally unregulated industry; It's like the old west, there are lots of cowboys, and just a few seasoned ranchers. Some of the freelance cowboys are experienced and know what they are doing. Many inexperienced freelance cowboys are eager to gain experience by working on your web development project. Inexperienced developers tend to be less successful than their more experienced counterparts, introducing a level of risk that would be unacceptable in other contracting industries.

Your Request For Proposal (RFP) document will determine who responds to your request with a proposal. Write it well and you'll hear from the dependable ranchers, seasoned cowboys, and the very risky inexperienced cowboys. Write the RFP poorly and you'll only hear back from the least dependable folks.

This blog series will explore the elements of a good RFP, what experienced developers respond to and what they don't respond to. Follow these guidelines and you'll be in good shape.

Improving Estimates for Web Projects at OSBridge

alexkroman — Wed, 22 Jun 2011 14:05:38 +0000

I'll be speaking today at 4:45 at Open Source Bridge on the topic of "Improving Estimates for Web Projects".

How many times have you received an email or phone call from a potential client who describes their project in a few sentences and expects a formal proposal the next day? This session will address this seemingly impossible task by going over the method we have created at OpenSourcery to estimate web projects. This method has helped us work with clients to prioritize functionality, set realistic schedules, and has improved our ability to close sales.

In this session you will learn:

* Alternatives to delivering a fixed hours estimate
* A simple method for quickly estimating projects from vague requirements
* How to work with developers, designers, and sales people to quickly deliver estimates
* Improving your estimation ability over time

Here's the link to the session:
http://opensourcebridge.org/sessions/580