Planning a sprint with software you don’t have

I my last post, An Agile Construction Project, I discussed Scrum and it’s various roles and meetings.  I briefly talked about how this framework could be used in the context of a commercial construction project, primarily driven by the GC.  One of the concepts discussed was the Sprint planning meeting.  This meeting is used to plan a specific time box.  I suggested using milestones already in place as a starting point for defining the time box.  During the sprint planning meeting all team members associated with activities identified within the project schedule would meet and plan the milestone in more detail.  Each trade would identify tasks and resources needed to complete each activity.  Doing this in a team setting, such as a sprint planning meeting, will keep the entire team informed of what work will be done within the sprint, what trades will be doing it, and any dependencies between tasks and activities.  Each trade is responsible for identifying its own tasks, task estimates, and resources needed to complete the tasks.  It is also responsible for tracking actual time spent on tasks (vs. estimates), and keeping the rest of the team informed on the progress of tasks (e.g., defined, in progress, completed).

That all sounds good in theory, but some may be wondering what this actually might look like and how it could be done in a non-disruptive manner.  How would the different trades enter all of their individual tasks into a system that is tied to the project schedule and accessible by all trades?  During my last year in the industry, Primavera (I think it was 10.0) was launching the first version of its web-based software.  This is a step in the right direction, and quite possibly, its latest version of the software may very well support task entry and tracking by all trades on the project.  But as I begin to pull together all of the different pieces of the Scrum framework over the next few posts, I suspect that the project planning tools currently used in the industry may not provide all of the functionality needed to implement the framework.  But, that’s fine because the framework is relativity simple in concept and there are plenty of free or low cost solutions that can be used to provide the functionality needed.  In the rest of the post, I’m going to show a simple application that I put together in a couple of hours, using free software, without writing a single line of code.  It’s the first few features of an overall application.  The application will allow the GC to easily upload the project schedule into a web-based application.  Different trades and users can be given access to the application via the web.  Trades can then enter tasks and resources associated with project activities and track progress.  The entire team can view daily progress.  I used Zoho Creator to build this application.

First I opened an existing project in Microsoft Project

Next, I exported the project as a CSV (comma-separated values) file and opened it in Microsoft Excel.

I then made some slight modifications to fit the format I wanted for my Zoho Creator application.  I also converted weeks into days.

I created an Activities View in my Zoho Application that includes columns for Activity Name, Description, State (e.g., defined, in progress, completed, and accepted), Duration (days), Owner (Subcontractor), and Sprint.   Within this view, I have the option to upload a CSV file.  I uploaded the one I created above.  You may notice that activities are already shown.  My screen shots are recreating the process I already went through for demonstrative purposes.

After the file has been imported, here is the display of the activities taken from the MS Project schedule

I’ve also created views for adding Users, Roles, and Contractors

Here, I’m adding a new contractor to the project in the Contractor View.

I can now add resources (people) for each contractor in my User View.  I’ll add a guy to the Signage contractor I just added to the system previously.

This user will now have access to the application, which can be used anywhere there is internet access.  This user is also now available to be assigned tasks!  Notice a few things in the following Activity View.  Starting at the far right column, each activity is currently assigned a sprint.  For this demo, the team would currently be planning for Sprint 4.  The owner belongs to the trade at the activity level.  The duration is in days.  The state for sprint 4 activities is currently defined because none have been started yet.  Notice that the state for Sprint 3 activities is set to Completed.  If you could see the activities for Sprint 2, the state would be accepted.  This is where acceptance tests come in for given activities.  Acceptance tests are for another post.  For now we’ll just stick to defined, in progress, and completed.

As stated above, for the purposes of this demo, the team is planning for Sprint 4.  All project activities have already been grouped into sprints.  All activities in Sprint 4 are currently in the defined state and have been assigned owners by trade.  At this point in sprint planning, the team would now create tasks for each activity and each trade would assign a resource as the owner of a task.  Under the Plan tab in the application, I’ll select the Tasks View.

And you can see that no tasks have been entered yet.

The team can now start adding tasks for each activity.  The team would rank the tasks in order of dependencies and assign them to an owner.  In this case it’s the Project Engineer.  Which makes sense because the task is associated with a punch list activity owned by the GC.  The task is assigned to Sprint 4, as expected.  Finally, because the task is assigned to the Project Engineer, it is up to him or her to assign an estimate.  In this case, one day.  Since the task has not been started yet, To Do is 1 day.

The result of the sprint planning meeting will be a task list with estimates and owners.  All activities must have tasks associated with them.  Once sprint planning is over, the team can begin implementation of the sprint.  The owners of each task are responsible for updating progress on the task.  For example, if the task I just created (Walk Area A for first inspection) was started, the Project Engineer would mark its state as In Progress.  Once the first task for any activity is started, the state for the activity is automatically changed to In Progress.  When all tasks have been marked complete for the associated activity, the  activity state is automatically updated to complete.  This will notify the owner of the activity that it is complete.  At this point, the owner of the activity would have specific acceptance criteria for insuring the completion of all tasks has fulfilled the desired outcome of the activity.  This is where acceptance tests come in.  A topic for another post.

*Zoho Creator is one of many custom application builders that can be used to create apps to meet your company’s unique needs and processes -in this case, the Scrum framework.  It requires little technical expertise, and apps can be created quickly with no overhead -the application is hosted, so there is no software to install.

An Agile Construction Project

Can an Agile approach be taken to construction Management?  Maybe, but what would it look like?

As a quick background, I spent 3 years in the commercial construction industry on the project management side.  I am currently a product owner in the software development industry.

Scrum in Software Development

This article looks at how a costruction project might take and Agile approach using the Scrum Framework.  Scrum is an iterative incremental framework for managing complex work commonly used with agile software development.  Although Scrum was intended for management of software development projects, it can be used as a general project/program management approach (http://en.wikipedia.org/wiki/Scrum_(development)).   The goal is to identify the highest priority requirements on a regular basis and specify which tasks are needed to fulfill those requirements in a Sprint Planning meeting.  Once the sprint has been planned, the team works on and finishes the tasks, and updates the team on task progress during a daily stand-up meeting, called the Daily Scrum.  At the end of each sprint, the team has a releasable product that can be presented to stakeholders during a Sprint Review.

The main roles in Scrum are; the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager); the “Product Owner”, who represents the stakeholders; the “Team”, a cross-functional group of people who do the actual analysis, design, implementation, testing, etc. (http://en.wikipedia.org/wiki/Scrum_(development).  Let’s look at these roles in more depth and see how they might be applied to construction management

The “Team” needs to be able to work undisturbed by external distraction throughout the sprint.  They are a self organizing group who pick what tasks, scheduled within the sprint, they will work on daily.  They are responsible for understanding dependences between tasks, and planning appropriately throughout the sprint.  Team members are welcome to engage stakeholders about details on requirements.  But outsiders should not themselves confront and disturb individual team members with question and input.  Instead, the ScrumMaster fields all outsider questions.

The “Scrum Master manages the process and protects the team from distractions. He removes all impediment so the team can keep moving forward.  The Scrum master inspires the team to do the right job, and may even have input on tasks.  He or she should have good communication skills, communicating with both the team and stakeholders.  The Scrum master must be able to gauge the status of the sprint.    The Scrum master takes responsibility for product delivery and inspires the team to deliver the expected product.

The Product Owner needs to understand the requirements and relay them to the team and answer and questions around the details.  The product owner needs to be able to make decisions on the fly as necessary, and take responsibility for those decisions.  He or she should time box everything from meetings to sprints.  The product owner should deliver general processes.  He or she should have an open and maintained backlog (contract documents in construction), allowing team members to review the backlog and begin to prioritize upcoming tasks.  There should be an input system in place that enables team members to give input on the backlog.  This allows the team to post real change requests and give input for areas of concern.

Both the Product Owner and the Scrum master work for the same objective: to enable the team to deliver a valuable product (in the case of construction, on time and within budget).  Both must have great trust in each other.  The Scrum master shouldn’t have to worry about not having the proper requirements and the product owner shouldn’t have to worry about daily work being competed.  In the construction industry, the Scrum master informs the product owner of requirements that cannot be implemented as first detailed

So, how could these roles be applied in the construction management process?

Scrum in Construction Management

Because we would want the team to remain somewhat small, we would probably want to limit team members to the foreman level.  The foreman for each trade would serve as a proxy for the subcontractor as a whole (that is, the implementation side).  I would think that for this process to really work, there would probably need to be some hierarchy of teams.  Each trade or subcontractor may also want to have it’s own Scrum master, Product Owner, and definition of a Team, as they are in a sense running their own mini projects, and have their own need to manage resources across other general projects.  But, for now we’ll just focus on the foreman level.

It seems to me that a Superintendent would be best suited for the Scrum master role.  He would be in charge of running the various Scrum meetings and working with the foremen on daily task and implementation details. He would identify obstacles that affect work progress and remove them.  Obstacles due to unclear or unimplementable requirements would be communicated to the product owner.

Optimally, I would see the Product Owner being an experienced Project Engineer.  It could also be the Project Manger, depending on the size of the overall project.  However, on a larger project, the Project Manager should really take on role similar to that of a Product Manager within the Scrum framework, understanding and dictating the vision for the overall project, aligning the project with internal corporate goals and external owner needs.  I’ll follow up on how the Agile process could be used in project selection and successful bidding.  This would also have implications on the Project Manager role.  For now, I’ll focus on the Project Engineer.  Playing the role of a product owner, the PE would need to fully understand all drawings, specifications, and contracts.  He or she would need to have all of this documentation readily accessible to the team for any planning and conflict resolutions needs.  All documents must be kept up to date, enabling all team members to have access to most current requirements.  As the team reviews the most current documents for sprint planning purposes, needs for change requests or RFIs may become present.  It becomes optimal to resolve these before the building process begins for the specific requirements in question. The PE must have tight feedback loop systems in place with all parties contributing to detailed requirements.  This means, at the minimum, the PE must be able to communicate with all architects and engineers involved in the design quickly and efficiently.  He will need these systems so that he can make decisions on the fly that can help the superintendent remove obstacles to building progress.  In many cases this may mean the team needs further clarification on some design detail, most likely resulting in an RFI of sorts.  The PE would ultimately be responsible for time boxing everything from various meetings, outside of sprint meetings, to sprint durations.  He would be in charge of maintaining and often creating general processes around the above listed interactions.

Meetings

Each day during a sprint there is a daily status meeting that takes place called a daily stand-up meeting.  During this meeting, all team members state what they did yesterday, what they are going to do today, and discuss any obstacles in their way, keeping them from accomplishing their goals or tasks.  Any larger issues that may or may not involve other team members are reserved as a parking lot issue that will be addressed directly following the meeting.  The meeting starts on time at the same time everyday.  The reason it’s called a stand-up meeting is because it’s supposed to be short enough that there’s really no need to sit down.  Ideally, the meetings should last all of 15 minutes a day.  It’s the job of the Scrum master to run these meetings.  So, in the construction industry, the superintendent would run this meeting, I would think, first thing in the morning, and would call on the foreman for each subcontractor on site.  If any obstacle were identified by the foremen, it would be on the superintendent to remove those obstacles.  This may involve the Product Owner, in our case the PE.  The PE would also be expected to attend these meetings and give his or her daily status update.  The daily stand-up meeting forces accountability on the GC and all trades and provides insight on the progress of the project on a day-by-day basis.  It also serves as an opportunity for coordination between all trades.  They will all know what each other are doing on a daily basis and will be able to further coordinate after the meeting.  By conducting the daily stand-up meeting religiously, the team will start to work as a well oiled machine and therefore increase efficiency and reduce rework.

I have talked a lot about sprints up to this point, and people reading this, not familiar with Agile Scrum, may be wondering what a sprint is.  In the software development world a sprint is a time-boxed period focused on completing a decided upon set of goals, activities, and tasks.  For the most part there are multiple sprints within a release.  A release represents a complete and sell-able product.  On the project I’m currently working on our sprints have a set duration of 4 weeks.  During these four weeks we work on a set of activities that we have planned to complete within the sprint.  The team gets together during the two day lag between each sprint and fleshes out the details of activities that they are planning to put into the next sprint.  Adding the activities to the sprint and planning resources takes place during the sprint planning meeting.

This is where I’m on the fence with how this would work in construction management.  If the team were to decide to work within regular (same duration), specific time frames for each sprint, the work might be a little bit difficult to split up. This also works best, when a schedule has not been decided upon up front in as much detail as a construction project schedule has.  Construction management does much of the design and planning up front, before the shovel ever hits the dirt.  This works well in the industry and it’s most likely not going to change anytime soon.  However, even with good planning up front, many unknowns present themselves throughout the project.  On my last construction project I believe we ended up with over 500 RFIs and several other forms of change to the contract documents, and I don’t believe this is all that uncommon.  With that many changes, there’s always opportunity to increase efficiency in the change process, as well as, reducing the amount of changes through process improvement!  Not all changes are due to incomplete design documents.  Many are a direct result of poor communication and coordination.  This is where I see opportunity to work more efficiently within specified time boxes that focus on specific chunks of work.  I see a lot of opportunity for efficient resource loading, as each trade can focus on the goals of the sprint and move resources as necessary from project to project.   So, instead of sprints all being the same duration, I would suggest starting with schedule milestones, as these often represent completed, even some times occupy-able, portions of the overall project. Milestones can very from the completion of a wing of a building to closing in the exterior.   For this reason, Project Engineers, most often with the help of Project Managers, will need to decide how best to split up the work and form these time boxes that can be used for sprint planning.

Once the milestones/sprint time frames have been chosen, the team can begin the sprint planning process.  This is where the goals, activities and tasks are detailed and resources are accounted for.  I really see great opportunity here.  Because the schedule is already in place, and the high level activities such as “frame in room A”, along with estimates, have been already worked into the schedule, the key here will be to accurately plan for resources.  As a side note, this is kind of the opposite way it happens with Agile projects in software development.  Usually the team has a set amount of resources and plans for what activities those resources can feasibly complete in a specific time box.  In the construction industry, resources are often moved from project to project on an as-needed basis.  During sprint planning, the team would sit down for a day and go through all of the upcoming activities and start to flesh out the task and resources needed to compete those activities.  The PE would lead the meeting, and I picture planning going something like this:

PE: ABC framers, I see we have an activity coming up in this sprint for framing and finishing room A.  We need to get this done by xyz day in the sprint in order to allow for the painters to get in behind you.  So, given this time frame and all other goals of this sprint, what tasks do you need to perform to complete this activity?  What are your estimates on these tasks?  What resources do you have and/or need to complete these tasks?

Framer: Well, we’ll need to complete 1,2, and 3 tasks, and with this short schedule, that will require us to have x amount of guys out here from this date to that date.

These types of conversations will provide valuable, in-depth insight into project tasks, and validate or invalidate current resource planning.  For instance, the framer may say “I can’t get the guys necessary to complete these tasks, within the given time frame.”  The issue is now in the open, and can be planned around by a talented team.  And because all trades that will be working within the sprint are represented, these work-arounds can be planned immediately and affectively!  After the meeting, all team members will have agreed upon and know what is expected to be completed within the sprint.  They will know what guys to get on site and when.  The reason this provides so much value, is because it keeps the entire team fresh and focused only on the work at hand.  Often times construction projects can run for many months and on into years.  It can be very difficult for the team to digest huge schedules and constantly be on top of resource planning.  It creates a very definable level of accountability and facilitates collaboration across trades!

In a perfect world, it would be highly beneficial to involve architects and engineers in sprint planning.  If it were my project, I’d force it.  In software development, the people who write the requirements and test them are always involved in these meetings.  That’s because all software must be testable and accepted.  In the same sense, this holds true in the construction industry.  I believe a good portion of the punch list can be knocked out incrementally.  Imagine this continuation of the above scenario and the value it would bring to the project:

Electrician: Before you guys dry-in, I’ve got to get my electrical stubbed out.  I’ve got the guys to do it quickly, so I don’t see it being much of an issue.  I just want you to be aware of it.  Also, I noticed that the hanging light fixtures don’t have a spec.  We need to get a submittal in on these, but aren’t sure what is wanted.  We can hang them in the next sprint, but there may be a substantial lead time for getting them here depending on the vendor.

Electrical Engineer: Oh, I’ve been meaning to send out an addendum on that.  We want to use vendor abc.  I’ll get the change out to you as soon as I get back to the office.  Also, I can come out that week and complete my punch list in this region if you like.

Superintendent:  I can also schedule the inspector.  Because we’re always prepared for him and make his life easy, he’s willing to come out multiple times throughout the project.

Framer: Yeah, this works for us.  Also, sense we’re on this subject, we noticed that the texture for the drywall wasn’t called out in the drawings for this room.  We’ve been using orange peel throughout most of the project.  Is this what we want here?

Architect: Yes, that works here.  I’ll put out an addendum for the finish drawings specifically calling this out.  Also, when I come walk the punch list, I’m going to be specifically looking for xyz.

This back and forth has gotten a lot of the key players on the team in sync and has already reduced time in RFI composition and possible rework for making incorrect assumptions.  The engineer and architect have specifically stated what they will be looking at on a punch list walk and the building inspectors are getting involved early in the project.  To me, this is what Agile is all about!  If the various items hadn’t been specified yet due to missing owner requirements, the A/Es could go get these now, or it could be brought up in the owners meeting.  The owner would then know the current stakes and would need to make a decision accordingly.  I see great opportunity in using some sort of this Scrum-like framework in the construction industry, and I hope this post intrigues industry professionals to consider adopting some flavor of this framework.  I believe it could provide a huge competitive advantage!

Upcoming follow-on concepts I hope to write about soon:

• The role of Project Manager within the scrum framework
• Agile effects on radically reducing task dependencies
• Paired programming: could this concept be applied to paired trade coordination?
• Modular, independent units: stagging
• Refactoring: change orders
• Flexible architecture that allows for decisions at the last possible moment
• Resource Allocation:  know how many guys you have, how many hours they work, and how much work can be done in those hours

A Quick Update

It has been almost a year since I posted iPhone and Android: Modular to Interdependent and Back to Modular Again and I thought I’d share a quick update.  I was reading the October 3rd-9th 2009 edition of The Economist and came across Cleverly Simple, an article about the current state of smart phones and a prediction of what this market might look like in the very near future.

Many eyes

I kind of forgot about this site until today.  It has some pretty cool visualization tools for simple data sets.  I just copied and pasted all the words in my blog so far into the site and used the word tree tool to generate this.  Just click on the image and it will take you to an interactive visual tool.  These can be embedded into any site.  However, I was having trouble inserting javascript directly into this post.  I’m sure it can be done, just not sure how to do it exactly.  It seems as though it has to be defined as a function first, just not sure where to put the file.  

 

The most profitable component(s) in the wind turbine

A few months ago a friend and I were discussing some investment opportunities.  He mentioned that he was considering investing in a company that produces blades for wind turbines.  I had read several research articles related to the economics of wind power and upon first thought it seemed to be a valid investment interest that could warrant further investigation.  At the time I didn’t give it a whole lot more thought than our brief conversation and I’m not even sure if he ever ended up investing in the company, or even which company it was. 

The Economist this last week was littered with articles and ads related to wind power and it got me to thinking on this subject a little more.  I was also reading some of Clayton Christensen’s thoughts on modular and interdependent architectures and how they relate to commoditization and can help managers predict profitability within an industry.  Specifically, I was looking at how to be profitable as a component of an overall modular architecture.  My research was for a completely different issue in a completely different industry, but my mind was sort of set in the mode and it made me wonder how versatile this framework actually was.  Could it be used to gain a better understanding of the wind turbine industry?  Could it reliably predict whether the blade (component) of the overall wind turbine system would be a performance-defining subsystem and command the highest profit margins, ultimately driving a successful company?  If it isn’t the blade, then what are the most profitable components in wind turbines?  I knew that if I wanted to successfully answer these questions, I needed to start by investigating the overall architecture of the industry, finding out where it was in the cycle of integration to modularization.

I briefly touched on modular and interdependent architectures in an earlier post, iPhone and Android: Modular to Interdependent and Back to Modular Again, but taking a quick second to review the concept in a little more depth before diving right in might be needed.

 

Interdependence and modularity

Interdependent architectures are systems in which one component or subsystem cannot be created independently of the other component.  That is, the design and manufacturing of one component depends on the design and manufacturing of another component.  The interface between two components has unpredictable interdependencies, usually requiring the same company to design and develop both components.  These architectures optimize performance, in both functionality and reliability.  The architecture also tends to be proprietary because of these unique interface designs –think Apple iPhone. Within modular architectures exist clean, specific, predictable interfaces that allow components to fit and work together in a well-understood, specified system.  This allows many component manufactures to compete in the market, as long as their products meet the specifications –think Windows OS.  

When a product or service is not yet good-enough, optimization, reliability and improved functionality are needed.  The goal is to make the best possible product out of the technology that is available.  Interdependent architectures allow firms to achieve this goal through integration of the design and manufacturing of every critical component needed to complete the overall system.  In the early stages of a new technology or service, integrated firms tend to make higher profit margins because their differentiation is straight forward and the high ratio of fixed to variable costs that is intrinsic in the design and manufacturing of interdependent products creates steep economies of scale.

However, there is a progression from interdependent to modular architectures as products improve enough to overshoot customer requirements (see Disruptive Technology subsection in previous post).  This leads to a performance surplus and speed, convenience and customization become important.  Modular architectures help firms compete on these dimensions because they can introduce new products faster by upgrading crucial individual subsystems without redesigning the entire system.  These firms begin to form standard interfaces.  Although standard interfaces may lead to some issues in the overall system performance, these issues will not be noticeable as there is already a performance surplus.  Standard interfaces enable independent, non-integrated firms to buy, sell and assemble components and subsystems. 

Finally, with modularity comes commoditization.  A modular architecture makes it very difficult to see or understand the differentiation in the performance or cost of a product versus those of the competitors, who use many of the same components in their own products due to standardization. Therefore, the attractive profits in the future will most likely be earned elsewhere in the value chain of the overall system or architecture.  Usually this happens in places in the formerly modular and undifferentiable processes, components, or subsystems.  The only way systems providers or assemblers (former interdependent architectures) can make profits in modular architectures is to find the very best performance-defining components in order to make the best possible product.   Their demand for improvements in performance-defining components throws the suppliers of those components back into the not-good-enough arena.  As a result, competitive forces compel suppliers of these performance-defining components to create interdependent, proprietary architectures within the subsystems. Hence, the performance-defining subsystems become de-commoditized as end-use products become modular and commoditized.

 

The wind turbine industry

Wow, that was a mouth full!  So, from here how do we now apply this framework to the wind turbine industry?  I figured the most important first step was to figure out where the industry is in the integration to modularization cycle.  Is it currently an interdependent architecture or a modular one?  So, I started by wrapping my head around the mechanics of a wind turbine and what components make up the overall unit.

I found that the turbine can be broken down into three major components which can then be broken down even further.  The rotor component includes the blades, hubs, pitch mechanisms and bearings, spinner and nose cone.  This accounts for roughly 20% of the overall turbine cost.  The generator components consists of a low-speed drive shaft, bearings, a gearbox, break, generator, variable speed electronics, hydraulic and cooling systems, a yaw drive and mainframe.  This major component accounts for roughly 34% of the overall system.  The structural support component is made up of the tower and the rotor pointing mechanism and is roughly 15% of the overall cost.  Each one of these components within the three major components has a material and labor cost that can be broken down into a percentage of the overall component.  For instance, in an advance blade component, the fiberglass fabric accounts for 60% of the cost, whereas the threaded metal fasteners accounts for 3% of the blade costs.  I’m not going to take the time to list all of these figures out here , they can be found in the sited document, but it is important to remember this concept.

O.K.  So there’s a lot of components here.  If we were to assume for the time being that the industry was currently working in an interdependent architecture –it is as will be discussed shortly– we would want to be able to reliably predict which of these components were best positioned to become the performance-defining components in the overall system as the industry moves to a more modular architecture.  Now whether it does or not and when, is still to be seen.  But, if this cycle was actually predictable in any industry, we would expect these turbines to eventually become good enough, be it in efficiency (the theoretical maximum efficiency of a turbine, worked out by Albert Betz, is 59.3% and modern turbines are about 50% efficient) or the price per kWh that would make it cheaper that alternative energy sources.  This would eventually produce a performance surplus, causing the customer to begin demanding improvements along the dimensions of speed, convenience and customization.  So, we would expect many of these turbine systems to start looking very similar in areas of efficiency and cost as their design begins to incorporate best practices, based on years of R&D and operation, and standardization begins to set in.  Customers will begin to exhibit higher bargaining power over turbine assemblers/manufactures because their products will be less differentiable.  Assemblers/manufacturers will turn to their components or subsystem suppliers and require innovative improvements that cut manufacturing or delivery times or allow for more customization and convenience for the customer.  We can see the cycle begin to take shape!

Alright, so this now causes competition among turbine component suppliers and forces their engineers to devise designs that are increasingly proprietary and interdependent in order to differentiate themselves from their competitors.  Their product must deliver the best performance in order to help differentiate the final, seemingly commoditized turbine from competitors’ turbines.  The leading providers of these components will find themselves profitably selling differentiated, proprietary products, increasing their supplier bargaining power.  So, back to the original question, which components are the ones best positioned to be a performance-defining subsystem?

To answer this question, the first thing I did was look to areas where improvements needed to be made.  This usually helps define the complexity of the system and identify those components that determine its performance.  From what I have found, we can expect there to be multiple solutions for these components, as they are not yet good-enough and many firms are developing different technologies to do the same thing, hoping that theirs will be the one that sets the standard.  I then investigated the overall design.  Because it is an interdependent architecture, the overall design plays a large role in the final product.  I wanted to see what components were being used and how many different substitutions there were for the various components.  These component suppliers would also be competing to set the standard.  Many of these may even overlap.  In wind turbine design, bigger is better.  For every increase in 10m of height, the wind speed can increase by 20% and the power output by 34%.  So, getting to those higher wind speeds is the goal.  However, there are barriers to how big these things can get.  There are issues with performance and durability in high wind speeds, geographical location, radar disruption and, oh yeah, transportation, construction and maintenance –ah, components that I had not yet considered.  These too are part of the interdependent architecture of the turbine industry.

 

Design

So, let’s start with design.  This includes tower height and diameter, blade count, rotation control, furling, and yawing –at least for this discussion as there are many other components that make up the overall design and I’m not trying to write a book here.   The tower, aside from aesthetics and space requirements, seems to be limited by strength of material, transportation and construction.  Doubling the tower height generally requires doubling the diameter and increasing the material by a factor of eight.  That seems pretty straight forward.  So, how about blades?

Modern turbines almost universally use either two or three blades. The aerodynamic efficiency of the system increases with the blade count but with diminishing return. Increasing the blade count from one to two yields a 6% increase in aerodynamic efficiency, whereas increasing the blade count from two to three yields only an additional 3% in efficiency.  Any additional increase in blade count yields minimal improvements in aerodynamic efficiency and sacrifices too much in blade stiffness as the blades become thinner.  However, cyclic stresses fatigue the blades, axel and bearings.  The backwards force and torque on a blade peaks when it is at the top of its rotation and is lowest when the blade is at the bottom of its rotation –when it is aligned with the tower.  These effects twist the bearings.  Therefore an odd number of blades is preferred so that there are no instances of one blade enduring the peak effects of force and torque while another is simultaneously aligned with the tower.  These two variables seem to dictate the three blade design, which is believed to be the dominate design in the industry for some time.  Looks like a standard is forming here!  Blades are also getting larger and larger mostly due to new types of materials and new manufacturing methods.  They are upwards of 80 meters in diameter. Fiberglass seems to be the dominate material currently and makes up 60% of the cost of the blade.  As blades get bigger and bigger, carbon may be necessary to provide the required stiffness.  Mass reduction as a function of blade length appears to be the goal. 

LM Glasfiber is a leader in turbine blade manufacturing.  Its new line of blades takes advantage of lower-weight root design.  Carbon is included in one blade, but not the other two, lower weight blades.  Another blade manufacturer, TPI Composites, is also looking to develop low weight blade designs.  It performed a low weight design study that used several technology improvements to reduce blade weight.  The study produced two blade designs, one was all fiberglass, the other included carbon fiber.  It also developed two root designs, one with 120 studs the other with 60 T bolts.  All four permutations of the blade and root design resulted in blades of similar mass and cost.  Interesting.  It sounds like they have similar products and are both innovating in the same areas of design.  Another point of interest here is what is advertised on the two competitors’ websites.  TPI is focused on its approach to blade supply, having focused factories that produce custom solutions that optimize cost and performance for its customers’ target markets.  It selects manufacturing sites that are local and optimize transportation and labor costs.  It has its own patented technology and combines it with its “error proof” manufacturing and in-house tooling systems.  LM Glasfiber strongly advertises it expertise in design and process/development innovation.  It has over fifty years of experience with glass fiber and holds over 29 patents on key discoveries and innovation.  Very interesting!

As for rotor control, today’s turbines are designed to spin at varying speeds.  These newer turbines can accelerate quickly in gusts of wind, improving the generation of electricity.  Typically wind turbines generate electricity through asynchronous machines that are directly connected with the electricity grid. Often the rotational speed of the wind turbine is slower than the equivalent rotation speed of the grid –typical rotation speeds for wind generators are 5-20 rpm while a directly connected machine will have an electrical speed between 750-3600 rpm. Therefore, a gearbox is inserted between the rotor hub and the generator. This also reduces the generator cost and weight.  Electrical generators inherently produce AC power.  In contrast to older style wind turbines, modern turbines are not governed by AC power line frequency.  This is because they incorporate technologies such as doubly fed induction generators or full-effect converters where the variable frequency current produced is converted to DC and then back to AC, matching the line frequency and voltage.  This requires expensive equipment and may lead to power loss, but at the same time turbines can capture a significantly larger portion of wind energy.  As it does not seem likely that turbines will go back to constant speed rotation or that power line frequency will be adapted for wind turbines, some sort of double fed induction generator, or generator/converter combination will be needed.  This appears to be the beginning of another standard interface.  There seem to be multiple solutions here with no clear winner yet, which means that this is one of those interfaces that is not quite good-enough yet.

Furling has an interesting affect on turbine design because it is needed to reduce induced drag from the lift of the rotor in strong wind gusts that cause sudden acceleration and to decrease audible noise levels.  It is done by changing the angle of the blades using some form of pitch angle control mechanism.  Older turbines used to use stalling methods, but it now seems that furling has become the standard for modern ones.  Currently, there are different types of pitch control systems being used in turbines.  Many turbines use hydraulic pitch control systems. These systems are usually spring loaded so that blades automatically furl in instances of hydraulic failure. Other turbines use an electric servomotor for every rotor blade.  This appears to be the more intelligent system of the two.  A servo is an automatic device which uses error-sensing feedback to correct the performance of a mechanism. These systems provide feedback or error-correction signals that help control mechanical positions –blade pitch– or other parameters.  Within this subsystem it is clear a standard has been set, in the sense that furling is the winning design.  What is not clear is which pitch control system will set the standard as turbines move to a more modular architecture.   At first glance, it would seem that a servomotor would allow for more room to innovate.  However, that additional performance may not be necessary.  Hydraulic systems may prove to be good-enough.

Finally, the yaw drive is used to control the turbine so that it is always facing the direction of the wind.  This usually includes some form of wind measurement and position correction system.  Once again, a standard appears to have formed, mandating efficient yaw angles in order to maximize power output and minimize non-symmetrical loads.  What is not clear is what the standard yaw control system will be.

Procurement, construction and maintenance

I’m not going to spend a lot of time on this, but there are some points of interest.  It is estimated that transportation costs can equal up to 20% of equipment costs.  That’s a lot of money!  This is because of the massive size of the blades, tower, gearbox and more.  Not only are they hard to transport, but they are very difficult to install.  Their components are large and heavy and require large expensive equipment and skilled operators to erect them.  What’s interesting about this component, is that it is part of the current interdependent architecture of the wind turbine system.  What I mean by this is that firms such as GE, Nordex and Vestas not only design and assemble wind turbines and some of their components, but also offer everything from project planning, to shipping and installation, to ongoing turbine maintenance and services.  This points to a very integrated architecture.  The evolution of this component will be very interesting as the industry moves to a more modular architecture.  If this were to be compared to something like the commercial construction industry, one would expect to see a few large general contractors that specialize in turbine construction.  They would be in charge of procuring materials, construction, budget maintenance, schedule and close-out –which may include operation and maintenance training.  They would have to follow some sort of specification put in place by an architect of sorts, whom would be working with the owner.  Who knows, as the turbine system becomes more modular, the contractor may be able to choose from a couple different blade suppliers that have been specified based on budget and subcontractor bids.   The thing to point out here, is that if this type of scenario ever did play out, the modular, more commoditized components would become easier to identify as they would become the components that the contractor would have multiple options from which to choose and then integrate into the overall project –it would be like choosing a brand of paint as long as it’s blue.

Geographic location

Both turbine vendors and power companies that buy the turbines employ teams of meteorologists to find the best places to put turbines. It is important to know when the wind blows and how powerfully. A difference of as little as one or two kilometers an hour in average wind speed can have an adverse effect on electrical output. They also have meteorologists sitting in the control centers, making detailed forecasts a day or two ahead to help a company manage its power load. If the wind stops blowing, the turbines stop turning. This is a great challenge for the spread and adoption of wind power.  Another issue is that people do not necessarily live where the wind blows. It is often the opposite. Resolution to this problem is a task for the electrical engineers who link turbines to places where power is needed. This means electricity grids must become bigger and smarter.  There are multiple components here that are not yet good-enough.  This could lead to an entire article in and of itself.  But for now, something to keep an eye on might be wind energy software that helps with infrastructure planning.

Radar

Ah, last but not least, radar.  Turbines create signal clutter.  They can interfere with radar used for air-traffic control.  There are even arguments that they can provide cover for enemy aircraft, causing security issues.  Again, pointing to an area of design that is not yet good-enough.  However, companies are finding ways to innovate around this problem.  For instance a company called Cambridge Consultants has invented what it calls holographic-infill radar.  In short, the moving blades on a turbine create a Doppler effect that returns signals that look like moving aircraft, making it hard to distinguish between the two.  Holographic-infill radar will create a so called “patch” over the entire wind farm, creating a moving radar picture of the farm.  Any unknown aircraft or object would be easy to spot.  The reason I added this section is because it may be problems and solutions like this that either hinder or advance wind power adoption and a truly innovative solution to a pressing problem could prove to be quite profitable.  After all, it may become standard practice to install holographic-infill radar on every farm. 

 

And…your final answer?

What’s really interesting to me is that as I really started to peel back all the layers of the turbine industry, I found that there are integration to modularization cycles taking place in many different tiers of the system, and in all different stages of the cycle.  It is not just the overall system that is currently interdependent, but many of its components as well.   There are also hints of components that are becoming more modular and inching ever closer to commoditization.  This has a lot to do with the fact that it is still an emerging technology, still evolving.  It is not clear that the architecture will soon become commoditized and move to a more modular structure, or that all of its components will become interdependent and de-commoditized.  Just the thought of saying turbines are becoming commoditized seems a bit silly.  Still, I find it fascinating how well this framework works.  It’s great for identifying the complexity of the overall system and gaining insight as to how all of the pieces fit together.  With some of the information we have, we can start to predict how the industry might look in the next 10 or so years.  We might be able to reasonably expect certain components and firms to be more profitable than others.  We can begin to see which of the components or subsystems are in good position to become performance-defining.  These will be the ones that set the standards that all other components will have to design and manufacture to.  Some standards will be dictated by natural forces, while others by innovation.  The key is to look for those components that will be dictated by standard interfaces -like a rotor hub that is designed to support exactly three blades.

If the cycle plays out and these large integrated firms do become more modular, it will be interesting to see where they niche, what components they decide to outsource or develop internally, what role they play in the assembly of turbines, the construction of them, or the services they provide for them.  Take for instance Vestas’s patented OptiSpeed technology.  Will this become the standard for double fed induction generators?  Or will its patented OpiTip technology set the standard for blade pitch control systems?  This probably depends on what Vesta’s core resources and capabilities are, and with those resources and capabilities, which component proves to be most profitable.  However it plays out, these are the type of complex components that I feel are best positioned to become performance-defining components and there is currently a lot of competition in these subsystems to become the standard.  Take a closer look at the two turbine diagrams in this post.  One is a GE assembled turbine, the other  a Vestas.  It is interesting to see where all of these components fit into the design and how similar, yet different they are.  You can almost start to picture where the standard interfaces are starting to take shape.

But since this whole thing started with turbine blades, that seems as good a place as any to finish, so here it is.  In my opinion, turbine blades are one of the components in the modern overall system, discussed in this posting, that are inching closer and closer commoditization.  This is not a bad thing.  The evolution of standards needs to happen for the overall industry to move to a more modular architecture.  And this is one of those subsytems in which standard interfaces appear to be forming.  When that happens, new opportunities for innovation will take shape.  But, for now it seems that blades are destined for commoditization.  I don’t think they can make up a performance-defining subsystem.  That does not mean that blade suppliers cannot be profitable.  As blade performance becomes good-enough in relation to the capability of the overall turbine, turbine assemblers like GE will begin to demand improvement along the dimensions of speed, convenience and customization.  So, if the design of the blade is good-enough, where might a blade supplier improve along these dimensions?  Transportation and logistics?  Customization for specific markets?  Which of the two blade suppliers that I mentioned earlier do you think is best positioned for modularization?  I’ll give you a hint, it just signed a long term agreement with GE to supply blades for its 1.5 megawatt wind turbine.

---

Chrristensen (2003). The Innovator’s Solution.  New York, NY: HarperCollins Publishers.  pg. 128

Chrristensen (2003). The Innovator’s Solution.  New York, NY: HarperCollins Publishers.  pg. 129

Chrristensen (2003). The Innovator’s Solution.  New York, NY: HarperCollins Publishers.  pg. 150

Chrristensen (2003). The Innovator’s Solution.  New York, NY: HarperCollins Publishers.  pg. 131

Chrristensen (2003). The Innovator’s Solution.  New York, NY: HarperCollins Publishers.  pg. 151

Chrristensen (2003). The Innovator’s Solution.  New York, NY: HarperCollins Publishers.  pg. 153

“Wind Turbine Design Cost and Scaling Model,” Technical Report NREL/TP-500-40566, December, 2006, page 35,36. http://www.nrel.gov/docs/fy07osti/40566.pdf

Wind Turbine Design,  http://en.wikipedia.org/wiki/Wind_turbine_design

Wind Turbine Design,  http://en.wikipedia.org/wiki/Wind_turbine_design

“Wind Turbine Design Cost and Scaling Model,” Technical Report NREL/TP-500-40566, December, 2006, page 35,36. http://www.nrel.gov/docs/fy07osti/40566.pdf

Wind Turbine Design,  http://en.wikipedia.org/wiki/Wind_turbine_design

Wind Turbine Design,  http://en.wikipedia.org/wiki/Wind_turbine_design

Servomechanism, http://en.wikipedia.org/wiki/Servo_motor

Wind Turbine Design,  http://en.wikipedia.org/wiki/Wind_turbine_design

Trade Winds, The Economist, June 19, 2008

Is it a plane?  The Economist, November 8, 2008

Happy Halloween!

iPhone and Android: Modular to Interdependent and Back to Modular Again

The first presentation given, on mobile devices, at Ignite Boulder last evening got me thinking about a document I wrote on this subject a while back. It was based on Clayton Christensen’s theories on disruptive technologies and modular vs. interdependent architectures. So, I thought I’d share why I believe that Android actually might make 2009 (maybe 2010) the year of mobile devices; as well as why I think it (and other open platforms in general) is best positioned to become the market leader. First though it is important to give a quick overview on the concepts of disruptive technology and modular vs. interdependent architectures as they will frame my argument. So here it is!

Disruptive Technology 

Here is a brief overview of Clayton Christensen’s theory on disruption. Figure 3-1 taken directly from pg. 44 of the Innovator’s Solution will aid in this discussion. The vertical axis represents the performance of a product and the horizontal axis represents time. The third axis represents new customers and new contexts for consumption. The slightly upward sloping dotted lines represent the rate of improvement customers can utilize and absorb within the specific market. The solid upward sloping lines represent improvements companies provide as they introduce new and improved products.

Low-end Disruption

The low-end disruption portion of the figure illustrates how technologies tend to progress faster than market demand. This happens when incumbent firms, often in an effort to provide better products than their competitors and increase their margins, overshoot their market. These companies earn better margins because they are typically adding new functions to their existing product and charging more for it, while at the same time investing less money in R&D. They end up giving customers more than they are willing to pay for. This does not mean all customers though. Customers in the highest, most demanding tiers may never be fully satisfied with a product’s performance, while those in the lowest tiers can be satisfied with very little. A disruptive product provides the customer with a new simple and more affordable way to accomplish only the tasks they deem important. It cuts away unneeded functionality and reduces costs associated with the extra functionality of sustaining products. Disruptive technologies that underperform today, may be performance competitive in the same market tomorrow. This happens because once a disruptive product gains a foothold in new low-end markets, an improvement cycle begins. Because the pace of technology is faster than the customer’s ability to absorb it, a previously seeming inferior product improves enough to compete in the market. This reveals a performance gap between sustaining products and disruptive products and allows entrants to enter the market.

New-Market Disruption

The new-market disruption portion of the graph represents new contexts of consumption and competition. These include new customers who previously lacked the money or skills required to buy and use the product, or different applications in which a product can be used. Although new-market disruptions initially compete against non-consumption, as their performance improves, they eventually become good enough to attract customers in sustaining markets, starting with the least demanding tier. Clayton Christensen provides a framework for determining whether a product is a new-market disruption in his books and scholarly articles. He discusses how a product or service addresses three business dimensions; the targeted product performance or features, the targeted customers or markets, and the business model implications, if it is to be a new-market disruption.

Specialists and Displacements

Christensen lists specialists that enter a market and displace integrated players as one of the three forms of industry change that takes place when incumbent firms overshoot their customer’s needs. Displacements take place at points of modularity, and I will discuss this concept in more depth in the following section. Unlike low-end disruptors that first target the least demanding customers, displacements first target the main stream market. They are considered specialists who focus on one component of a product or service. Displacements can rattle incumbent firms because they often require the firm to rethink how it segments its market. Incumbents that are organized around defined product segments often find it difficult to respond when a new entrant segments the same market differently.

Device Architectures

Since I left off with displacement in the above section, I will start by continuing that concept in terms of interdependence and modularity. The device industry has taken on a more modular architecture like that of the computer. To be clear, by devices I mean intuitive mobile solutions comprised of operating systems, applications and functional interfaces. Apple’s iPhone is a benchmark for these types of devices. Apple’s product offerings have always been developed in a proprietary, interdependent architecture as all components are specified and interfaced by Apple. See figure 3-2. Interdependent architectures optimize performance, in terms of functionality and reliability. When product functionality and reliability are not yet good enough to address the needs of customers in a given tier of the market, companies must compete by making the best possible products. Companies that develop their products around proprietary, interdependent architectures have a competitive advantage over those whose product architectures are modular. The reason being is due to standardization, modular architectures involve too many companies and products in the design process and ultimately hinder optimal performance.

This was the case in the smartphone industry. The majority of smartphones where being developed around modular architectures involving many partners, who were producing products that were still not good enough for their customers in terms of functionality. The largest issue related to functionality was the limited internet browsing capabilities these smartphones had. This was the case because until Apple introduced its multi-touch, button-less interface, smartphones where not being designed intuitively. They were using pressure sensitive, one-point touch-screens designed around limited mobile applications. By introducing a multi-touch surface on a device, Apple was able to transform an industry simply by changing the way we interact with technology. A year or so later some of the largest companies, including Google and its Android platform, are working hard to come out with multi-touch, intuitive interface based devices of their own.

As an interdependent, integrated architecture was needed to change an industry, a modular architecture will be needed to bring competing products to the industry quickly. The reason this transition will take place so fast here is because Apple found an innovative way to incorporate existing technologies into the right market application. Multi-touch technology has been around for twenty years, it just wasn’t being used in the best applications. Because the technology is not new, projects like Google’s Android platform and OpenMoko’s open source platform have adopted modular architectures in order to bring competing products to the market quickly. By having open and modular platforms they can involve many manufactures and developers in the design process of various devices.

As the industry becomes more modular, the devices will become more commoditized. The reason being is as the architecture becomes more modular, the overall product becomes less proprietary and the subsystems that make up the overall product become more proprietary. This then gives the modular subsystem suppliers bargaining leverage over the device hardware manufacturer. Once again the best performance-defining components will have the most power over the overall product design. Figure 3-3 demonstrates how profitability starts to fall from the overall product down into the various subsystems.

Wasn’t that fun!

---

[i] Christensen (2003). The Innovator’s Solution. Boston, MA: Harvard Business School Publishing. pg. 43

Christensen (2003). The Innovator’s Dilemma. New York, NY: HarperCollins Publishers. pg. xix

Chrristensen (2003). The Innovator’s Solution. New York, NY: HarperCollins Publishers. pg. 45

Christensen (2003). The Innovator’s Solution. Boston, MA: Harvard Business School Publishing. pg. 51

Christensen (2003). The Innovator’s Solution. Boston, MA: Harvard Business School Publishing. pg. 51

Christensen (2003). The Innovator’s Solution. Boston, MA: Harvard Business School Publishing. pg. 51

Christensen (2004). Seeing What’s Next. Boston, MA: Harvard Business School Publishing. pg. 12

Christensen (2004). Seeing What’s Next. Boston, MA: Harvard Business School Publishing. pg. 27

Christensen (2003). The Innovator’s Solution. Boston, MA: Harvard Business School Publishing. pg. 154

Christensen (2003). The Innovator’s Solution. Boston, MA: Harvard Business School Publishing. pg. 153

Christensen (2003). The Innovator’s Solution. Boston, MA: Harvard Business School Publishing. pg. 129