Make It Happen
My Tipsheets are chock full of ideas. They are all aimed at translating knowledge into action...in a quick, action-oriented 60-second nugget.

First Name:
Last Name:
email:
Tipsheet Archive
Randall's Resources
Whenever I speak or write, I often prepare extra "bonus" materials.
Enter the Resource Code to access this special content:
Resource Code:
Try this example Resource Code: eventplanning

Development

Agile Methodology

by Randall Craig on March 17, 2017

Filed in: Blog, Make It Happen Tipsheet,

Tagged as: , ,

Project managers the world over build Gantt charts, PERT charts, Work Breakdown Structures.  They focus on delivering on-time, on-budget.

No matter your role, is there something that can be learned from the profession of project management?

In the olden days – and sadly, “today” for many organizations – the most common project management approach is the so-called waterfall approach:

  • Market research
  • Analysis of requirements
  • Technical specification
  • Development
  • Testing
  • Bug-fixes
  • Final testing
  • Launch

This approach allowed for clear approvals at each stage, and cleverly separated the “client” of the project from those actually doing the work.

Unfortunately, this methodology has some significant disadvantages, chiefly that because of this separation, there is little or no collaboration during the project itself.  Said another way, the ground can shift during long projects, and therefore the needs may change significantly from the project start to project launch.

Enter Agile.  While the dictionary defines agile as “the ability to move quickly and easily”, from a project management perspective, agile means something very specific.  Instead of a long, drawn-out process, an agile process divides the project into a number of cycles, called sprints.  Each sprint would have three parts:

  1. Build:  Something is put together (a prototype, a pilot, etc)
  2. Test:  The kinks are worked out of the system.
  3. Demo:  Feedback is collected for action during the next sprint.

Agile Project Management

Agile provides a number of advantages over the traditional waterfall approach:

  • Real-time market research is embedded into the process.
  • There is collaboration and connection to the target users.
  • Continuous mid-course corrections and improvements.
  • Lower project risk, since progress is demonstrated continuously.
  • Faster time-to-market.

This week’s action plan:  While the example above might be for a digital development project, agile can be used anywhere.  Consider the projects that you are connected with: how many are managed traditionally, and how many are agile?  This week, begin the process of moving at least one to agile.

Note: The Make It Happen Tipsheet is also available by email. Go to www.RandallCraig.com to register.

Randall Craig

@RandallCraig (follow me)
www.RandallCraig.com
:  Professional credentials site
www.108ideaspace
.com: Web strategy, technology, and development
www.ProfessionallySpeakingTV.com
:  Interviews with the nation’s thought-leaders

 

{ 0 comments }

Have you ever received proposals from several vendors for the same web project, only to see a significant difference in their fees?  While a tightly specified RFP is supposed to guard against this, when it happens, there should be no real surprise. Here’s why:  Every respondent will go (or should go through) a detailed costing and work effort estimation, effectively multiplying the rate by the number of hours.

Like their clients, each vendor needs to make enough money to stay in business: rent, technology,  salaries, training, and the myriad of other costs need to be covered.  So if the developer bids a low price in order to win, then they need to find ways to cut corners.

In an earlier post, we described these pressures in greater detail, and suggested ways that the selection process can be improved.  This week, we expose 15 shortcuts that clients need to be aware of – and head off at the pass.

15 ways developers can cut corners:

1) Scope creep strategy: Bid low just to sign the contract, and then increase the contract value through later change requests.

2) Razor blade strategy: take a loss on the website build, but make it up on onerous support annuities.  This is no different than what happens with razor blades or ink jet printers.  Mitigation:  compare total cost of ownership, including all ongoing external and internal costs.

3) Onerous exit costs at website end-of-life.  This is typical when the site is built on a proprietary content management system or the developer hosts the site at their facility.  Mitigation: ask about the exit costs – and then put it into the contract.

4) Skip the built-in SEO:  There are about a dozen search-engine-enhancing development activities that should be implemented during the site build: from descriptive ALT tags, custom TITLE tags on each page, H1/H2/H3 tags, keyword density, friendly URLs, etc.  It’s easier to win an engagement when this work effort is completely omitted from the proposal.   And it’s easier to justify a follow-up engagement to improve SEO, often on a monthly fee-for-service basis. Mitigation: Review sites that the developer has already built, and see if these are incorporated.

5) Bait and switch:  This occurs when those who sell the engagement aren’t doing the work.  A slick salesperson will learn about the organization and its needs write the proposal, do the pitch, but when someone else – usually a junior – is slotted in to do the work, that learning must happen all over again.  The project budget then gets used to redevelop relationships and learn about the business – not on the deliverables.  Mitigation: Determine if the key project team members are involved in the early business development process.

6) Misleading portfolio: Who actually did the beautiful work in the web firm’s portfolio?  Often, it was done over the years by former employees, freelancers, and interns – none of who will be on the engagement.  When it is the same team who did the work in the past, it is more likely that past performance will be an indicator of the quality (and timeliness) of the work that is done in the future.  Mitigation: Do not accept portfolio examples or case studies where the proposed project manager AND designer were not intimately involved in the project.

7) Outsourced to third parties/brokers:  Typically, this happens when the web firm is more development-oriented than design-oriented.  By outsourcing design, the actual designer is disconnected from your requirements: user experience design and branding work profits hugely with direct interaction with the designer – both during design discovery, and throughout the process.  When outsourced, this knowledge disconnect will increase project risk – and cost.  Mitigation: Ask the firm how many of their design team are full-time employees, vs part-timers, contractors, freelancers, outsourced, or “partners”.  Ask if any of these types of individuals will be doing any work on your project.

8) One-click install: Many technologies, WordPress chief amongst them, can be installed through a standard “one-click” process on a webhost. The problem is that this is inherently insecure, and your custom site is custom… not “standard”.  But using this capability can save time… which can then be recaptured with a later change request.   Mitigation: For WordPress, go to one of their existing client websites, and go to the “standard” wp-admin login page (eg www.sitename.com/wp-admin).  If you see a login page, chances are it is a one-click install, not a customized installation.

9) No firewall security: The most valuable asset for every organization is their reputation. When a web server is hacked, reputation and trust are quickly lost.  Budget pressures can cause security corners can be cut – and sometimes completely ignored.  Mitigation: Securing a site takes a significant amount of effort.  See above – wp-admin – for a quick test, but it’s best to ask them specifically what they do to secure the site.

10) No documentation: Documentation includes everything from strategy documents, to functional requirements, technical specifications, to a visual identity guide, to in-line commenting within the code, to to user manuals. Skipping (or skimping) on any of this mostly invisible work is a great way to bring down the initial cost.  Mitigation: If there is no mention of the documentation in the proposal, then it’s not included.  To look under the hood yourself, review the HTML code from one of their clients: are comments embedded within the code?  (Note:  In order to speed the site, better web developers will “minify” the code before publishing a final version of the site – this is not a foolproof check.)

11) Do-it-yourself hosting:  It’s financially tempting to capture annuity income  hosting a website at the web developer’s facility.  And the more sites on a particular piece of hardware, the higher the margin.  The developer then trades this forever profit for cheaper web development pricing.  The problem with this approach is that in 90% of the cases, web sites should really be hosted on scalable cloud-based servers, with redundant internet connections and hardware.  Think the Amazon cloud, not a web developer’s closet or a consumer $8/month plan. Mitigation: ask detailed questions about their hosting recommendations.

12) No performance testing or optimization:  Performance testing and optimization is really a double negative for developers: it takes time to do, and when issues are found, then they must be fixed… on the developer’s dime.   The unethical developer much prefers to leave Pandora’s expensive box closed.  Mitigation: ask about what they do to optimize the site for speed.  Then test the site pre-launch using web-based automated tools to determine whether everything that could be done, has been done.

13) Templated design:  Why create a completely new design, when you can use a variant of a design (and the underlying code) that has worked perfectly well many times before?  Mitigation:  Look at the developer’s portfolio: does each site look completely unique, and reflect the brand of the organization?

14) Semi-accessible: In many jurisdictions, legislation (“AODA” is one example) now requires that new websites be developed to be accessible to people with disabilities.  To create a site that is fully accessible means significant additional effort: different (and more) coding, different design, and additional testing.  It’s far easier to skip the heavy lifting, and not bother with some of the hidden work.  Mitigation:  After the site is delivered, ask a third party to certify the site for compliancy.  Or, ask the developer to prove that the site is compatible.

15) Responsive plug-in:  Instead of spending time doing custom designed layouts that are optimized for tablets and smartphones, the developer can install a free plug-in that does 30% of the work – and provides 30% of the benefit.  While you might see a mobile-style drop-down menu and a few other minor changes, all of the heavy lifting is omitted: the result is a poorer user experience and reduced  conversion.  Mitigation: Make sure that during the development process, you sign-off on customized responsive screens.

The vast number of developers are ethical, hardworking, and do not look for shortcuts: the pressures of profitability – and sometimes unreasonable selection processes – can sometimes force a behavior that is not in a client’s best interest.

This week’s action plan:  If you have recently built a new site, use this list as a checklist: how did you do?  If a new site is on the horizon, make sure that you are comparing apples with apples – and that your selection process does not force developers to cut corners.  The best way to do this is before the RFP even goes out: have an open discussion with prospective partners, and see how many of these items they even bring up.

Editorial comment:  There is considerable nuance to each of the items in this post.  And each item may have a different value to any particular client: for example, some clients might not care about site speed, so performance testing and optimization need not be done.  The purpose of this post (and the first part) was to foster a more transparent, knowledge-based discussion – and therefore improve the outcome of the project for all involved.

An open discussion:  If you are considering a web project in the next 12 months, and are interested in an open discussion about your selection process, please don’t hesitate to reach out.

 Note: The Make It Happen Tipsheet is also available by email. Go to www.RandallCraig.com to register.

Randall Craig

@RandallCraig (follow me)
www.RandallCraig.com
:  Professional credentials site
www.108ideaspace
.com: Web strategy, technology, and development
www.ProfessionallySpeakingTV.com
:  Interviews with the nation’s thought-leaders

{ 0 comments }