Bootstrapping Vs. Building for Scale


#1

Hello All.

I thought it would be interesting to hear some thoughts from the community
about the tensions between bootstrapping and building for scale.

In recent years, the ict4d projects that I’ve worked on have had limited
budget and time with which to demonstrate their viability. Prototypes have
been minimum viable products and they have definitely not bee built for
scale. The focus is on the user’s experience and sacrifices are made when
it comes to the backend or administrative functions, with device
compatibility, with appearance, with functionality and so forth.

When I imagine the opportunity to truly follow Digital Development
Principle #6: Build for Scale, my brain races at all of the strategic
considerations and I enjoy contemplating the possibility of sitting down
with our users and coders and drawing out the grand architecture of a
product that could meet our needs and grow with our community.

But, my reality is a steady sequence of small iterations, each generally
enough to meet the essential demands of a new partner (new language, new
content modules, branding tweaks) and too little to embark on serious
upgrades to the core of the digital product. Nevertheless, we are scaling
and the non-flashy requirements of building for scale are slowly piling up.

Has anyone else in this situation thought through the priorities of
building for scale in a slow, granular fashion?


#2

Nathaniel

One approach to manage the tension between limited budgets/need for quick
iterative results and building for scale is to build on top of existing
framework – whether it is web application frameworks like Drupal or
DotNetNuke or open source Rich Client Platforms like Eclipse. If you have
a well-connected environment you can also look at chunking up the services
you provide taking a SOA approach.

If you have to build a scalable, complex platform from the ground up with a
limited budgets through quick iterative releases, then you have an
interesting challenge….

Best Regards

[image: cid:image002.jpg@01D0FDC1.FE1CCC40]

Jonathan Palmer

Director Global Information and Communication Technology

Wildlife Conservation Society

··· ☎: +1 718 741 8160 | + 1 347 566 0030 |skype: wcs.org_jpalmer | Calendar

web: http://www.wcs.org

twitter: https://twitter.com/thewcs

From: ict4d-principles@googlegroups.com [mailto:
ict4d-principles@googlegroups.com] *On Behalf Of *Nathaniel Calhoun
Sent: Tuesday, December 01, 2015 7:57 PM
To: ICT4D Principles ict4d-principles@googlegroups.com
Subject: [ICT4D Principles] Bootstrapping Vs. Building for Scale

Hello All.

I thought it would be interesting to hear some thoughts from the community
about the tensions between bootstrapping and building for scale.

In recent years, the ict4d projects that I’ve worked on have had limited
budget and time with which to demonstrate their viability. Prototypes have
been minimum viable products and they have definitely not bee built for
scale. The focus is on the user’s experience and sacrifices are made when
it comes to the backend or administrative functions, with device
compatibility, with appearance, with functionality and so forth.

When I imagine the opportunity to truly follow Digital Development
Principle #6: Build for Scale, my brain races at all of the strategic
considerations and I enjoy contemplating the possibility of sitting down
with our users and coders and drawing out the grand architecture of a
product that could meet our needs and grow with our community.

But, my reality is a steady sequence of small iterations, each generally
enough to meet the essential demands of a new partner (new language, new
content modules, branding tweaks) and too little to embark on serious
upgrades to the core of the digital product. Nevertheless, we are scaling
and the non-flashy requirements of building for scale are slowly piling up.

Has anyone else in this situation thought through the priorities of
building for scale in a slow, granular fashion?


You received this message because you are subscribed to the Google Groups
"ICT4D Principles" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Click here
https://www.mailcontrol.com/sr/q+BzBn3CpMnGX2PQPOmvUq6rRgRshdaJRB4RwNzcXw6fadPk++zEAPJhip8imfkK9IbX4436LeOiyla!1rT5xQ==
to report this email as spam.


#3

@Jonathon, great points about leveraging open platforms. Under all the
customizations, we do that; but per your second post, we typically drive
resources towards implementation and leave a tiny portion for tech–20% or
considerably less. And that’s paying for wireframing, consensus-building
with all partners, actual dev, testing and reporting. On small budgets, it
leaves us choosing between anything more complex than new
content–translated into multiple languages and entered by several
different teams.

For context, the project that’s got me thinking supports facilitators of
savings and credit groups in recruiting and facilitating these groups over
at least six months. It layers meeting content with trainings, various
resources and embedded M&E. It does this in English, Amharic and Tanzanian
Kiswahili.

@Jean: don’t apologize for joining the discussion! Your comments are super
welcome and well reasoned. In my particular case, I have partners who are
generally responsible for drumming up implementing partners and funds
(usually I’m not so lucky); but that’s why my question was quite
tech-focused.

@Siobhan, you’re correct about the typical usage of “bootstrap.” As the
partners in our coalition responsible for proving to funders and
implementing partners that they made a solid wager on our technological
tool, I still find myself in a position much like bootstrapping: I have
limited resources with which I must achieve the most memorable and
measurable possible victories in my market. It’s a relentlessly strategic
process; but it feels like building to survive this season of the Hunger
Games and not building for scale in the sense that I have to kick things
down the road that I would logically invest in now, especially if they
wouldn’t be noticed or vocally appreciated in the current project cycle.

That’s why I end up juggling between:

  1. Things that please my facilitators and implementers who report vocally
    on a weekly basis and influence their org’s continuing involvement.
  2. Things that enable us to gather, organize and analyze data about the
    usage of our product and the experience of our users – stuff that’s great
    for donors, write-ups and dev diagnostics.
  3. Things that would please funders or implementing partners that we
    haven’t yet attracted–such as new thematic content.
  4. Developments that help to democratize usage of our tool: design for new
    screen sizes, additions of new languages, support for other operating
    systems, apks with social sites to increase virality.

and so forth.

@gmc: good point. I’ve been on both sides of that: orgs that throw away
tech investments too casually instead of recycling and capturing value and
orgs that are totally stuck with their tech for financial reasons and
pushing against its limitations. Ultimately, the type of scenario that I
described will be significantly different in each case, so perhaps best
practices or guidelines may not emerge. Although, I’d probably consider my
list above to be in order of priority.

Thanks all for jumping in!

··· On Wednesday, December 2, 2015 at 8:57:20 AM UTC+8, Nathaniel Calhoun wrote: > > Hello All. > > I thought it would be interesting to hear some thoughts from the community > about the tensions between bootstrapping and building for scale. > > In recent years, the ict4d projects that I've worked on have had limited > budget and time with which to demonstrate their viability. Prototypes have > been minimum viable products and they have definitely not bee built for > scale. The focus is on the user's experience and sacrifices are made when > it comes to the backend or administrative functions, with device > compatibility, with appearance, with functionality and so forth. > > When I imagine the opportunity to truly follow Digital Development > Principle #6: Build for Scale, my brain races at all of the strategic > considerations and I enjoy contemplating the possibility of sitting down > with our users and coders and drawing out the grand architecture of a > product that could meet our needs and grow with our community. > > But, my reality is a steady sequence of small iterations, each generally > enough to meet the essential demands of a new partner (new language, new > content modules, branding tweaks) and too little to embark on serious > upgrades to the core of the digital product. Nevertheless, we are scaling > and the non-flashy requirements of building for scale are slowly piling up. > > Has anyone else in this situation thought through the priorities of > building for scale in a slow, granular fashion? >

#4

Hi,

I’m new to the list. My name is Jean and I’ve been working for the World
Bank in some Open Innovation and Social Accountability projects in Africa
and Latin America.

I totally fell in love with the ICT4D Principles from the moment I first
saw them. First of all for its interesting guidance but most importantly
because it gave a formal support to the way I believe we should be doing
ICT projects in general.

I’d like to jump into this discussion and bring some thoughts about
scalability and sustainability.

Bootstrapping is at the same time one of the most appealing and most risky
characteristics of what we can do to solve problems through technology.

It is true that we can do a lot with very little, but too often I’ve seen
people overemphasizing what can be done with ICT that totally disregard the
community and organizational support that needs to be provided for projects
to bring sustainable impact and change.

When I think about building for scale, I tend to think about selecting
appropriate technologies but it is also about selecting the appropriate
institutional arrangements for a project to bring impact at wider scales.
This goes far beyond code and architectures and it also relates to the way
the project works and how it involves people in the change we want to bring.

This is where scalability and sustainability are intrinsically connected.

On the other hand, it is very difficult to think about scale when our
successful pilots are not linked to “scalable” funding instruments that
will enable them to grow or even to transfer.

Being condemned to do daily basis management of scarce resources with a
strong uncertainty towards future funding frequently leads us to reduce the
ambition of the projects and to prove concepts that will enable the
projects to survive.

Having a constant need to prove concepts in a short term basis and
developing good scalable solutions with all these constraints is frequently
very difficult to achieve.

Ideally, I would tend to think that we would need to:

  • Make people understand that investment in ICT does not totally change
    the rules of the game, community support and communication campaigns will
    always be needed. Good support to local organizations so that they can
    operate in new ways is also necessary. These things cost money, most
    probably they will cost even more than ICT development but they are crucial
    to have a successful investment.
  • Bootstrapping is nice but it cannot always be sustainable. ICT
    projects cannot always be on a short term basis expecting immediate gains.
    Sometimes they require strategic thinking and stability to properly plan
    for the impact they want to achieve.
  • Scalable solutions require this stability to have a more efficient
    usage of resources.
  • ICT is not always about experimenting and doing nice pilots. When you
    start something, you need to at least have had some thoughts about how
    you’re able to support it to bring it to another scale: with possible lines
    of funding and also in operational terms.

Sorry for jumping into the discussion. These are just my two cents =)

Best,

Jean

Jean Barroca

··· On 2 December 2015 at 02:25, Jonathan Palmer wrote:

Nathaniel

One approach to manage the tension between limited budgets/need for quick
iterative results and building for scale is to build on top of existing
framework – whether it is web application frameworks like Drupal or
DotNetNuke or open source Rich Client Platforms like Eclipse. If you have
a well-connected environment you can also look at chunking up the services
you provide taking a SOA approach.

If you have to build a scalable, complex platform from the ground up with
a limited budgets through quick iterative releases, then you have an
interesting challenge….

Best Regards

[image: cid:image002.jpg@01D0FDC1.FE1CCC40]

Jonathan Palmer

Director Global Information and Communication Technology

Wildlife Conservation Society

:phone:: +1 718 741 8160 | + 1 347 566 0030 |skype: wcs.org_jpalmer | Calendar
https://www.google.com/calendar/hosted/wcs.org/embed?src=jpalmer@wcs.org

web: http://www.wcs.org

twitter: https://twitter.com/thewcs

From: ict4d-principles@googlegroups.com [mailto:
ict4d-principles@googlegroups.com] *On Behalf Of *Nathaniel Calhoun
Sent: Tuesday, December 01, 2015 7:57 PM
To: ICT4D Principles ict4d-principles@googlegroups.com
Subject: [ICT4D Principles] Bootstrapping Vs. Building for Scale

Hello All.

I thought it would be interesting to hear some thoughts from the community
about the tensions between bootstrapping and building for scale.

In recent years, the ict4d projects that I’ve worked on have had limited
budget and time with which to demonstrate their viability. Prototypes have
been minimum viable products and they have definitely not bee built for
scale. The focus is on the user’s experience and sacrifices are made when
it comes to the backend or administrative functions, with device
compatibility, with appearance, with functionality and so forth.

When I imagine the opportunity to truly follow Digital Development
Principle #6: Build for Scale, my brain races at all of the strategic
considerations and I enjoy contemplating the possibility of sitting down
with our users and coders and drawing out the grand architecture of a
product that could meet our needs and grow with our community.

But, my reality is a steady sequence of small iterations, each generally
enough to meet the essential demands of a new partner (new language, new
content modules, branding tweaks) and too little to embark on serious
upgrades to the core of the digital product. Nevertheless, we are scaling
and the non-flashy requirements of building for scale are slowly piling up.

Has anyone else in this situation thought through the priorities of
building for scale in a slow, granular fashion?


You received this message because you are subscribed to the Google Groups
"ICT4D Principles" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Click here
https://www.mailcontrol.com/sr/q+BzBn3CpMnGX2PQPOmvUq6rRgRshdaJRB4RwNzcXw6fadPk++zEAPJhip8imfkK9IbX4436LeOiyla!1rT5xQ==
to report this email as spam.


You received this message because you are subscribed to the Google Groups
"ICT4D Principles" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


#5

Some very interesting comments here.

Just to reinforce from a combined ICT4D and enterprise systems and web startup perspective.

The limiting factor in any ICT4D project is never ever going to be the technology. For a few dollars a month I can rent hosting and database services on AWS, throw one of numerous options for coding there, pay some really good engineers $20 / hour to build an app and have something that could scale technologically to tens of thousands or millions of people. It’s that easy and cheap today with the right technologists. To Siobhan’s point good technologists are worth 10-100 times the mediocre ones though. If you find the right people they might well donate their time, or you could ask around in the community too…

My own observation of ICT4D scalability limitations come from:

  •      Not the right requirements – not asking the right people the right questions
    
  •      Not enough governance and stakeholder management – not ensuring that decision makers are participating and owning their decisions and supporting the projects
    
  •      No process design – these should come first
    
  •      Inadequate planning – rushing in to development before you have through the options and potential problems
    
  •      Not the right testing – not planning testing and being disciplined about it
    
  •      Poor project management – anyone ever seen that?
    
  •      No operational planning – if you are deploying technology to 1000s of people, what is your support plan? Procurement plan? Replacement plan? Budgeting plan? Monitoring plan? Processes?
    
  •      Not enough thought to change management – this is a huge. The hard part of implementing technology is not the technology, unless you are Jeff Dean, it’s the people. How do you persuade 10s, 100s or 1000s of people to change what they are doing and trust their time, priorities, careers and reputations to your project?
    
  •      Short budget cycles – it’s hard to scale from scratch to thousands of people in 3 years when the first 6 months are spent starting up and hiring and the last 6 in closeout.
    
  •      Sector limitations – we take on national-size problems with
    

o locality sized budgets

o in areas of incredible need

o that have often low human and infrastructure capacity

o where we often need collaboration with (and approval from) multiple partners

o and must meet national ministry mandates

What’s interesting is that most of these problems have been solved for decades in various places. Great change management is not a new science. Implementing complex systems rapidly to tens of thousands of people is not even noteworthy in many places. It’s worth reaching out to resources within your organization, online, at universities, in corporate…people are often very willing to help.

Great conversation…
E

Ernest Ostro | Director, Software Systems
International Rescue Committee
122 East 42nd Street, NY, NY 10168 | Rescue.org
M. +1 347 688 2225| skype. ostro.ernest

··· From: ict4d-principles@googlegroups.com [mailto:ict4d-principles@googlegroups.com] On Behalf Of Nathaniel Calhoun Sent: Wednesday, December 02, 2015 3:01 PM To: ICT4D Principles Subject: [ICT4D Principles] Re: Bootstrapping Vs. Building for Scale

@Jonathon, great points about leveraging open platforms. Under all the customizations, we do that; but per your second post, we typically drive resources towards implementation and leave a tiny portion for tech–20% or considerably less. And that’s paying for wireframing, consensus-building with all partners, actual dev, testing and reporting. On small budgets, it leaves us choosing between anything more complex than new content–translated into multiple languages and entered by several different teams.

For context, the project that’s got me thinking supports facilitators of savings and credit groups in recruiting and facilitating these groups over at least six months. It layers meeting content with trainings, various resources and embedded M&E. It does this in English, Amharic and Tanzanian Kiswahili.

@Jean: don’t apologize for joining the discussion! Your comments are super welcome and well reasoned. In my particular case, I have partners who are generally responsible for drumming up implementing partners and funds (usually I’m not so lucky); but that’s why my question was quite tech-focused.

@Siobhan, you’re correct about the typical usage of “bootstrap.” As the partners in our coalition responsible for proving to funders and implementing partners that they made a solid wager on our technological tool, I still find myself in a position much like bootstrapping: I have limited resources with which I must achieve the most memorable and measurable possible victories in my market. It’s a relentlessly strategic process; but it feels like building to survive this season of the Hunger Games and not building for scale in the sense that I have to kick things down the road that I would logically invest in now, especially if they wouldn’t be noticed or vocally appreciated in the current project cycle.

That’s why I end up juggling between:

  1. Things that please my facilitators and implementers who report vocally on a weekly basis and influence their org’s continuing involvement.
  2. Things that enable us to gather, organize and analyze data about the usage of our product and the experience of our users – stuff that’s great for donors, write-ups and dev diagnostics.
  3. Things that would please funders or implementing partners that we haven’t yet attracted–such as new thematic content.
  4. Developments that help to democratize usage of our tool: design for new screen sizes, additions of new languages, support for other operating systems, apks with social sites to increase virality.

and so forth.

@gmc: good point. I’ve been on both sides of that: orgs that throw away tech investments too casually instead of recycling and capturing value and orgs that are totally stuck with their tech for financial reasons and pushing against its limitations. Ultimately, the type of scenario that I described will be significantly different in each case, so perhaps best practices or guidelines may not emerge. Although, I’d probably consider my list above to be in order of priority.

Thanks all for jumping in!

On Wednesday, December 2, 2015 at 8:57:20 AM UTC+8, Nathaniel Calhoun wrote:
Hello All.

I thought it would be interesting to hear some thoughts from the community about the tensions between bootstrapping and building for scale.

In recent years, the ict4d projects that I’ve worked on have had limited budget and time with which to demonstrate their viability. Prototypes have been minimum viable products and they have definitely not bee built for scale. The focus is on the user’s experience and sacrifices are made when it comes to the backend or administrative functions, with device compatibility, with appearance, with functionality and so forth.

When I imagine the opportunity to truly follow Digital Development Principle #6: Build for Scale, my brain races at all of the strategic considerations and I enjoy contemplating the possibility of sitting down with our users and coders and drawing out the grand architecture of a product that could meet our needs and grow with our community.

But, my reality is a steady sequence of small iterations, each generally enough to meet the essential demands of a new partner (new language, new content modules, branding tweaks) and too little to embark on serious upgrades to the core of the digital product. Nevertheless, we are scaling and the non-flashy requirements of building for scale are slowly piling up.

Has anyone else in this situation thought through the priorities of building for scale in a slow, granular fashion?

You received this message because you are subscribed to the Google Groups “ICT4D Principles” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ict4d-principles+unsubscribe@googlegroups.commailto:ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.commailto:ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


#6

Jean

Useful comment – and you are 100% right – products don’t scale because of
the technology – poor technology choices can constrain the ability of a
product to scale – but in most cases what determines whether something
scale is the degree to which it is embraced by a community - which is
typically driven by marketing the product to their needs and by ensuring
the product is implemented and supported in a way that drives success.

As a starting rule of thumb for developing technology projects I want to
see no more than 20% of resources go on solution development and 80% go
towards implementation (including product testing and marketing). The ICT
Principles are right in terms of user centric design but they make too many
assumptions that scalability-of-technology delivers scale – they need to
emphasize the part of the iceberg under the water – building for
scalability needs to be unpacked so funders and program staff understand
the heavy lifting need to get solutions deployed at scale.

Best Regards

[image: cid:image002.jpg@01D0FDC1.FE1CCC40]

Jonathan Palmer

Director Global Information and Communication Technology

Wildlife Conservation Society

··· ☎: +1 718 741 8160 | + 1 347 566 0030 |skype: wcs.org_jpalmer | Calendar

web: http://www.wcs.org

twitter: https://twitter.com/thewcs

From: Jean Barroca [mailto:jeanbarroca@gmail.com]
Sent: Wednesday, December 02, 2015 4:27 AM
To: Jonathan Palmer jpalmer@wcs.org
Cc: Nathaniel Calhoun natecalhoun@gmail.com; ICT4D Principles <
ict4d-principles@googlegroups.com>
Subject: Re: [ICT4D Principles] Bootstrapping Vs. Building for Scale

Hi,

I’m new to the list. My name is Jean and I’ve been working for the World
Bank in some Open Innovation and Social Accountability projects in Africa
and Latin America.

I totally fell in love with the ICT4D Principles from the moment I first
saw them. First of all for its interesting guidance but most importantly
because it gave a formal support to the way I believe we should be doing
ICT projects in general.

I’d like to jump into this discussion and bring some thoughts about
scalability and sustainability.

Bootstrapping is at the same time one of the most appealing and most risky
characteristics of what we can do to solve problems through technology.

It is true that we can do a lot with very little, but too often I’ve seen
people overemphasizing what can be done with ICT that totally disregard the
community and organizational support that needs to be provided for projects
to bring sustainable impact and change.

When I think about building for scale, I tend to think about selecting
appropriate technologies but it is also about selecting the appropriate
institutional arrangements for a project to bring impact at wider scales.
This goes far beyond code and architectures and it also relates to the way
the project works and how it involves people in the change we want to bring.

This is where scalability and sustainability are intrinsically connected.

On the other hand, it is very difficult to think about scale when our
successful pilots are not linked to “scalable” funding instruments that
will enable them to grow or even to transfer.

Being condemned to do daily basis management of scarce resources with a
strong uncertainty towards future funding frequently leads us to reduce the
ambition of the projects and to prove concepts that will enable the
projects to survive.

Having a constant need to prove concepts in a short term basis and
developing good scalable solutions with all these constraints is frequently
very difficult to achieve.

Ideally, I would tend to think that we would need to:

  • Make people understand that investment in ICT does not totally change
    the rules of the game, community support and communication campaigns will
    always be needed. Good support to local organizations so that they can
    operate in new ways is also necessary. These things cost money, most
    probably they will cost even more than ICT development but they are crucial
    to have a successful investment.
  • Bootstrapping is nice but it cannot always be sustainable. ICT
    projects cannot always be on a short term basis expecting immediate gains.
    Sometimes they require strategic thinking and stability to properly plan
    for the impact they want to achieve.
  • Scalable solutions require this stability to have a more efficient
    usage of resources.
  • ICT is not always about experimenting and doing nice pilots. When you
    start something, you need to at least have had some thoughts about how
    you’re able to support it to bring it to another scale: with possible lines
    of funding and also in operational terms.

Sorry for jumping into the discussion. These are just my two cents =)

Best,

Jean

Jean Barroca

On 2 December 2015 at 02:25, Jonathan Palmer jpalmer@wcs.org wrote:

Nathaniel

One approach to manage the tension between limited budgets/need for quick
iterative results and building for scale is to build on top of existing
framework – whether it is web application frameworks like Drupal or
DotNetNuke or open source Rich Client Platforms like Eclipse. If you have
a well-connected environment you can also look at chunking up the services
you provide taking a SOA approach.

If you have to build a scalable, complex platform from the ground up with a
limited budgets through quick iterative releases, then you have an
interesting challenge….

Best Regards

[image: cid:image002.jpg@01D0FDC1.FE1CCC40]

Jonathan Palmer

Director Global Information and Communication Technology

Wildlife Conservation Society

:phone:: +1 718 741 8160 | + 1 347 566 0030 |skype: wcs.org_jpalmer | Calendar https://www.google.com/calendar/hosted/wcs.org/embed?src=jpalmer@wcs.org

web: http://www.wcs.org

twitter: https://twitter.com/thewcs

From: ict4d-principles@googlegroups.com [mailto:
ict4d-principles@googlegroups.com] *On Behalf Of *Nathaniel Calhoun
Sent: Tuesday, December 01, 2015 7:57 PM
To: ICT4D Principles ict4d-principles@googlegroups.com
Subject: [ICT4D Principles] Bootstrapping Vs. Building for Scale

Hello All.

I thought it would be interesting to hear some thoughts from the community
about the tensions between bootstrapping and building for scale.

In recent years, the ict4d projects that I’ve worked on have had limited
budget and time with which to demonstrate their viability. Prototypes have
been minimum viable products and they have definitely not bee built for
scale. The focus is on the user’s experience and sacrifices are made when
it comes to the backend or administrative functions, with device
compatibility, with appearance, with functionality and so forth.

When I imagine the opportunity to truly follow Digital Development
Principle #6: Build for Scale, my brain races at all of the strategic
considerations and I enjoy contemplating the possibility of sitting down
with our users and coders and drawing out the grand architecture of a
product that could meet our needs and grow with our community.

But, my reality is a steady sequence of small iterations, each generally
enough to meet the essential demands of a new partner (new language, new
content modules, branding tweaks) and too little to embark on serious
upgrades to the core of the digital product. Nevertheless, we are scaling
and the non-flashy requirements of building for scale are slowly piling up.

Has anyone else in this situation thought through the priorities of
building for scale in a slow, granular fashion?


You received this message because you are subscribed to the Google Groups
"ICT4D Principles" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Click here
https://www.mailcontrol.com/sr/q+BzBn3CpMnGX2PQPOmvUq6rRgRshdaJRB4RwNzcXw6fadPk++zEAPJhip8imfkK9IbX4436LeOiyla!1rT5xQ==
to report this email as spam.


You received this message because you are subscribed to the Google Groups
"ICT4D Principles" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


#7

Jean and Jonathan/Nathaniel make excellent observations below. Having worked in ICT4D for more than 30 years I’ve seen my share of failures and successes. One clear pattern emerges: successes in scaling put building and nurturing broad stakeholder partnerships first. The technology and support structures were then tested, adapted, enhanced, and changed with the support of the stakeholder partnership to meet changing needs. This may include, in the process, even abandoning one technical approach for another in response to changing needs and emerging technologies. If we don’t get the stakeholder mapping and partnership right, scaling is highly improbable.

We are in a age of venture capital approaches that provide 1) very limited resources to prove feasibility in the lab, 2) more resources for demonstrating feasibility in the field, and 3) more resources for scaling up. The quick and dirty initial prototype may not be designed for scale. The burden is on Step 2 to build an architecture and business model that can, and to prove that by load testing and other means. This should include testing the extent to which the application generalized. It’s easy to falter in this step. We need to ask and confront the hard questions sooner in the process.

Cheers,

-gmc

Gordon M. Cressman
Senior Program Director | Research Computing Division | RTI International
Email: gmc@rti.orgmailto:gmc@rti.org | Office: +1 919 541-6363 | Mobile: +1 919 271-7003 | Skype: gmcressman

Was this email too brief? Here is whyhttp://emailcharter.org/

··· From: <ict4d-principles@googlegroups.com> on behalf of Jonathan Palmer <jpalmer@wcs.org> Date: Wednesday, December 2, 2015 at 9:02 AM To: Jean Barroca <jeanbarroca@gmail.com> Cc: Nathaniel Calhoun <natecalhoun@gmail.com>, ICT4D Principles <ict4d-principles@googlegroups.com> Subject: RE: [ICT4D Principles] Bootstrapping Vs. Building for Scale

Jean

Useful comment – and you are 100% right – products don’t scale because of the technology – poor technology choices can constrain the ability of a product to scale – but in most cases what determines whether something scale is the degree to which it is embraced by a community - which is typically driven by marketing the product to their needs and by ensuring the product is implemented and supported in a way that drives success.

As a starting rule of thumb for developing technology projects I want to see no more than 20% of resources go on solution development and 80% go towards implementation (including product testing and marketing). The ICT Principles are right in terms of user centric design but they make too many assumptions that scalability-of-technology delivers scale – they need to emphasize the part of the iceberg under the water – building for scalability needs to be unpacked so funders and program staff understand the heavy lifting need to get solutions deployed at scale.

Best Regards

[cid:image002.jpg@01D0FDC1.FE1CCC40]

Jonathan Palmer
Director Global Information and Communication Technology
Wildlife Conservation Society
:phone:: +1 718 741 8160 | + 1 347 566 0030 |skype: wcs.org_jpalmer | Calendarhttps://www.google.com/calendar/hosted/wcs.org/embed?src=jpalmer@wcs.org
web: http://www.wcs.org
twitter: https://twitter.com/thewcs

From: Jean Barroca [mailto:jeanbarroca@gmail.commailto:jeanbarroca@gmail.com]
Sent: Wednesday, December 02, 2015 4:27 AM
To: Jonathan Palmer <jpalmer@wcs.orgmailto:jpalmer@wcs.org>
Cc: Nathaniel Calhoun <natecalhoun@gmail.commailto:natecalhoun@gmail.com>; ICT4D Principles <ict4d-principles@googlegroups.commailto:ict4d-principles@googlegroups.com>
Subject: Re: [ICT4D Principles] Bootstrapping Vs. Building for Scale

Hi,
I’m new to the list. My name is Jean and I’ve been working for the World Bank in some Open Innovation and Social Accountability projects in Africa and Latin America.
I totally fell in love with the ICT4D Principles from the moment I first saw them. First of all for its interesting guidance but most importantly because it gave a formal support to the way I believe we should be doing ICT projects in general.
I’d like to jump into this discussion and bring some thoughts about scalability and sustainability.
Bootstrapping is at the same time one of the most appealing and most risky characteristics of what we can do to solve problems through technology.
It is true that we can do a lot with very little, but too often I’ve seen people overemphasizing what can be done with ICT that totally disregard the community and organizational support that needs to be provided for projects to bring sustainable impact and change.
When I think about building for scale, I tend to think about selecting appropriate technologies but it is also about selecting the appropriate institutional arrangements for a project to bring impact at wider scales. This goes far beyond code and architectures and it also relates to the way the project works and how it involves people in the change we want to bring.
This is where scalability and sustainability are intrinsically connected.
On the other hand, it is very difficult to think about scale when our successful pilots are not linked to “scalable” funding instruments that will enable them to grow or even to transfer.
Being condemned to do daily basis management of scarce resources with a strong uncertainty towards future funding frequently leads us to reduce the ambition of the projects and to prove concepts that will enable the projects to survive.
Having a constant need to prove concepts in a short term basis and developing good scalable solutions with all these constraints is frequently very difficult to achieve.
Ideally, I would tend to think that we would need to:

  • Make people understand that investment in ICT does not totally change the rules of the game, community support and communication campaigns will always be needed. Good support to local organizations so that they can operate in new ways is also necessary. These things cost money, most probably they will cost even more than ICT development but they are crucial to have a successful investment.
  • Bootstrapping is nice but it cannot always be sustainable. ICT projects cannot always be on a short term basis expecting immediate gains. Sometimes they require strategic thinking and stability to properly plan for the impact they want to achieve.
  • Scalable solutions require this stability to have a more efficient usage of resources.
  • ICT is not always about experimenting and doing nice pilots. When you start something, you need to at least have had some thoughts about how you’re able to support it to bring it to another scale: with possible lines of funding and also in operational terms.

Sorry for jumping into the discussion. These are just my two cents =)

Best,

Jean

Jean Barroca

On 2 December 2015 at 02:25, Jonathan Palmer <jpalmer@wcs.orgmailto:jpalmer@wcs.org> wrote:
Nathaniel

One approach to manage the tension between limited budgets/need for quick iterative results and building for scale is to build on top of existing framework – whether it is web application frameworks like Drupal or DotNetNuke or open source Rich Client Platforms like Eclipse. If you have a well-connected environment you can also look at chunking up the services you provide taking a SOA approach.

If you have to build a scalable, complex platform from the ground up with a limited budgets through quick iterative releases, then you have an interesting challenge….

Best Regards

[cid:image002.jpg@01D0FDC1.FE1CCC40]

Jonathan Palmer
Director Global Information and Communication Technology
Wildlife Conservation Society
:phone:: +1 718 741 8160tel:%2B1%20718%20741%208160 | + 1 347 566 0030tel:%2B%201%20347%20566%200030 |skype: wcs.org_jpalmer | Calendarhttps://www.google.com/calendar/hosted/wcs.org/embed?src=jpalmer@wcs.org
web: http://www.wcs.org
twitter: https://twitter.com/thewcs

From:ict4d-principles@googlegroups.commailto:ict4d-principles@googlegroups.com [mailto:ict4d-principles@googlegroups.commailto:ict4d-principles@googlegroups.com] On Behalf Of Nathaniel Calhoun
Sent: Tuesday, December 01, 2015 7:57 PM
To: ICT4D Principles <ict4d-principles@googlegroups.commailto:ict4d-principles@googlegroups.com>
Subject: [ICT4D Principles] Bootstrapping Vs. Building for Scale

Hello All.

I thought it would be interesting to hear some thoughts from the community about the tensions between bootstrapping and building for scale.

In recent years, the ict4d projects that I’ve worked on have had limited budget and time with which to demonstrate their viability. Prototypes have been minimum viable products and they have definitely not bee built for scale. The focus is on the user’s experience and sacrifices are made when it comes to the backend or administrative functions, with device compatibility, with appearance, with functionality and so forth.

When I imagine the opportunity to truly follow Digital Development Principle #6: Build for Scale, my brain races at all of the strategic considerations and I enjoy contemplating the possibility of sitting down with our users and coders and drawing out the grand architecture of a product that could meet our needs and grow with our community.

But, my reality is a steady sequence of small iterations, each generally enough to meet the essential demands of a new partner (new language, new content modules, branding tweaks) and too little to embark on serious upgrades to the core of the digital product. Nevertheless, we are scaling and the non-flashy requirements of building for scale are slowly piling up.

Has anyone else in this situation thought through the priorities of building for scale in a slow, granular fashion?

You received this message because you are subscribed to the Google Groups “ICT4D Principles” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ict4d-principles+unsubscribe@googlegroups.commailto:ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.commailto:ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Click herehttps://www.mailcontrol.com/sr/q+BzBn3CpMnGX2PQPOmvUq6rRgRshdaJRB4RwNzcXw6fadPk++zEAPJhip8imfkK9IbX4436LeOiyla!1rT5xQ== to report this email as spam.

You received this message because you are subscribed to the Google Groups “ICT4D Principles” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ict4d-principles+unsubscribe@googlegroups.commailto:ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.commailto:ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups “ICT4D Principles” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ict4d-principles+unsubscribe@googlegroups.commailto:ict4d-principles+unsubscribe@googlegroups.com.
To post to this group, send email to ict4d-principles@googlegroups.commailto:ict4d-principles@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.