The Lessons Learned Survey

Another useful tool in the Lessons Learned process is the Lessons Learned Survey.  This is a survey that can be sent to team members during or after a project, to solicit their feedback on how the project was conducted. It applies to any project; and questions can easily be added to focus on additional areas for your project.

A survey like this can be very useful for capturing lessons learned from the project while they’re fresh in people’s mind. The results can be summarized and recommendations passed on to future teams.

It’s usually best to send this survey by email to members of the project team. Let them know that results can be kept anonymous (to encourage people to be frank in their assessments). Send out this survey before any group “lessons learned” meetings. The feedback you receive from the survey can help point to particular areas that should get special exploration in the group lessons learned meeting.

Again, use this if it’s meaningful to your projects – it’s just another template or project tool that I’ve picked up along the way and wanted to share with our readers.  I’ve found it to be helpful in gathering post-project information from my team members on several key projects.

Post-Project Survey

SECTION 1: General Project Issues and Communication

The questions are geared to your particular project but wherever appropriate you can comment about release-level issues too.

Note: add any particular comments you wish….

1. How clearly defined were the objectives for this project?

___Very ____somewhat ___not very ___not at all

2. How clearly defined were the objectives for your work?

___Very ____somewhat ___not very ___not at all

3. How clear were you on your role in the project?

___Very ____somewhat ___not very ___not at all

4. How adequately involved did you feel in project decisions?

___Very ____somewhat ___not very ___not at all

If you did not feel involved, what decisions did you feel left out of?

5. How efficient and effective were project team meetings?

___Very ____somewhat ___not very ___not at all

What would you change?

6. How efficient and effective were technical meetings?

___Very ____somewhat ___not very ___not at all

What would you change?

___Very ____somewhat ___not very ___not at all

8. How adequate has cross-functional participation been?

___Very ____somewhat ___not very ___not at all

What were the problems encountered in the project-functional area relationship, why, and how could they be fixed? What cross-functional participation, if any, was lacking?

9. Do you feel appreciated, recognized and rewarded for your efforts?

___Very ____somewhat ___not very ___not at all

What if anything has been lacking?

10. To what degree is do you feel the entire team was committed to the project schedule?

___Very ____somewhat ___not very ___not at all

What if any issues are there?

11. To what degree have any “people issues” gotten in the way?

___Very ____somewhat ___not very ___not at all

What issues?

12. What communication, organization, structural problems in general were encountered, and how could we have done better in these areas?

SECTION 2: Schedule Estimation Issues

NOTE: This survey isn’t intended to collect exhaustive data on everything right now. We might decide after the post-mortem to work with a sub-group to investigate certain estimation issues, in order to help us improve next time around. This survey just helps us ferret out the rough scope of any issues.

Which of the following estimation issues did you personally have and what was the impact?

___ I was diverted to work on another project full-time.

Project: ________________________________________ Diverted for how long? ________________

Impact on your project work: ____________________________________________________________

___ I overestimated the amount of time I would have each week to work on this project.

The other work that interfered was ________________________________________________________

The amount of time per week it took up was ________________________________________________

Impact: calendar schedule slip of ____days ____weeks ____ months

___ My initial schedule did not include some pieces of technical design or coding work that I subsequently realized I had to do.

Describe briefly: ______________________________________________________________________

Impact (additional hours of work): ________________________________________________________

___ My initial schedule did not take into account certain project “other” work such as attending other people’s design reviews, doing two rounds of my own design reviews, etc.

Describe: ____________________________________________________________________________

Impact: calendar slip to my work of __ days __ weeks __ months

___ My estimates for particular tasks were not accurate.

Describe: type of task, how “off” the estimate was (days, weeks).

Why was it difficult to estimate?

What would help produce better estimates next time?

__ I unexpectedly had to re-do some work.

Describe: (Did something in the system design change that forced you to redesign? Was there a spec misunderstanding? etc.)___

Impact on your schedule: _______________________________________________________________

What could have helped prevent the problem?

Knowing what you know now, how would you do the scheduling/estimating process differently next time to avoid any problems noted above?

SECTION 3: Design, Implementation, Test Processes

1. How effective was our architecture/system design process in phase 2 and 3?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

2. How effective were our functional specs?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

3. How effective were our design (or implementation) specs?

__Very __somewhat ___not very ___not at all

Comments:__________________________________________________________________________

4. How effective were our design reviews?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

5. How effective were our code reviews or hardware reviews?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

6. How well were interfaces defined?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

7. How well were design and interface decisions documented?

__Very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

8. How effective has interaction/cooperation between technical “Sub-teams” been?

___Very ____somewhat ___not very ___not at all

Comments:_________________________________________________________________________

9. How useful was your unit testing?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

Did you take unit testing into account in your schedule? ______________________________________

10. How smooth do you feel Integration has been?

__very __somewhat ___not very ___not at all

Comments (why/why not?):___________________________________________________________

11. How comprehensive was integration testing, especially to allow SQA testing to get off to a good start?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

12. How well is the build process working?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

13. To what degree did you have the tools you needed for testing?

__very __somewhat ___not very ___not at all

Comments:_________________________________________________________________________

SECTION 4: Perceived Project Life Cycle, Development, or Process Issues

1. Is there any way in which you think our development process hampered this project?

If so, how?

2. What would you change about our development process?

3. What would you like to better understand or see better documented about how to use our process on this type of project?

SECTION 5: Closing

1. What were up to 5 main causes for schedule slips, and how could we avoid those causes in the future?

2. Was the project significantly delayed/hampered by outside dependencies (outside to the project, that is)? Which ones? How can we resolve these issues?

3. What were the main bottlenecks on the process?

4. What were the main sources of frustration in the project?

6. For the next project, how could we improve on the way project was conducted?

Construction Software State of the Industry from Software Advice

My friends at Software Advice have sent over another interesting original article that they have put together pertaining to software in the construction industry. This one comes from Houston Neal and it kicks off a series of reports the group is doing on trends within the construction software industry. Please visit their site at www.softwareadvice.com for the original report.

Construction Software State of the Industry Report

This is the first in a series of “state of the industry” reports in which we will share our observations on construction software industry trends. While reporting the recessive state of the industry is not breaking news, there are some interesting trends that we can share. Not everything is gloomy, and significant technological shifts are underway.

Our observations are based on roughly 6,000 conversations with construction software buyers over the past year. In these calls, our team listened to buyers’ “pain points” – the business problems they were looking to solve with new software. From there, we recommended what we felt were the best solutions. We later surveyed each buyer to find out if they ended up buying software, what they bought and how it all went.

Estimating and takeoff solutions are in demand

We’ve seen a very healthy level of interest in construction estimating software across all divisions. Over and over we hear contractors saying something to the effect of, “Bidding has gotten very competitive, which means I’ve got to be as accurate as possible.” As a result, we’ve seen a lot of estimators replacing their spreadsheets and manual processes with database-driven estimating systems.

We’ve also seen plenty of interest in on-screen takeoff software. We’ve seen three primary reasons for this:

• Increasing the speed and accuracy of takeoff measurements (see previous paragraph);
• Avoiding the printing costs of paper plans; and,
• Responding to increasing electronic plan delivery and use of online plan rooms.

While demand for onscreen takeoff appears fairly strong and growing, we have seen a considerable amount of downward pricing pressure in that market.

Software as a Service is in the right place at the right time

Software as a Service (SaaS) is gaining momentum in many software markets. In fact, we would agree with other IT prognosticators that SaaS is a major structural shift in software deployment and is here to stay. We’ve seen this model succeed in the project management segment where there is a clear need for the collaborative benefits of web-based software. Moreover, the current recession is making the SaaS model more attractive to contractors because:

• Subscription pricing can easily be added to a project’s general conditions;
• Low up-front costs allow project managers to avoid an onerous approval process; and,
• Faster and less expensive implementation makes the new systems more digestible.

We have not seen much demand for SaaS accounting, estimating or service management, although we do get asked about it now and then. We also have not seen many vendors emerge to deliver that sort of solution. We would not be surprised to see SaaS accounting and/or estimating solutions emerge over the next few years.

LEED credit tracking creates new demand

Another trend driving the adoption of SaaS project management systems is the increasing demand for LEED credit tracking. LEED certification has grown in popularity; so too has the need to track the detailed documentation requirements related to earning LEED credits. At their core, projects seeking LEED certification need document control and efficient communication. This is the core of what project management systems deliver. Going one step further, we are seeing a number of project management vendors building in specific LEED credit tracking modules within their system. Houston Neal wrote a great post on how to Track LEED v3 Credits in Project Management Software back in July.

Stimulus funds are trickling down, slowly

Government and other civil construction has remained healthier than commercial and residential construction. However, we have not seen the American Recovery and Reinvestment Act of 2009 (ARRA) have a big impact on software spending. We believe that the temporary nature of stimulus spending is not enduring enough to drive capital investment in software systems. Our hope is that ARRA will help accelerate the economy to a point where traditional IT investment levels resume. However, Chris Thorman recently wrote a quick analysis of the ARRA that showed that stimulus spending has had a nominal effect on putting roughly 1.6 million unemployed construction workers back on the job.

There has been speculation that Stimulus-funded construction projects would drive sales of project management software. The thinking behind the forecast was that ARRA projects would require a higher level of accountability. Project management software – known for strong document tracking capabilities – would provide the audit trail needed for this transparency. However, we have not seen this translate into a meaningful increase in sales.

Fewer accounting & job costing replacements

We’ve seen fewer firms replacing their core accounting and job costing systems over the last year. In prior years, we had seen replacement activity when company growth pushed existing systems to their limits. In the absence of growth, more firms seem to be staying put with their existing systems. Firms that are buying new accounting systems tend to identify one or more of the following three pain points:

• Inability to achieve detailed job cost reporting from “generic” accounting systems;
• Lack of integration to project management or service management systems; and,
• The need to accomplish same amount of work with fewer employees.

Outlook for 2010

As the construction industry begins to rub its sleepy eyes, we agree with most experts who say that 2010 will be a transitional yet slow year for the industry as a whole. Company budgets likely won’t fully recover in 2010, limiting the purchase of construction software. However, so far we’ve noticed more activity this quarter than any other this year. Hopefully this level of interest will carry over to 2010.

This article originally published at: Construction Software State of the Industry Report.

Zoho Launches Sign-In Integration With Google Apps

Sourced from the Washington Post ( written Leena Rao for Techcrunch )

Last summer, Zoho, a web-based software suite that includes document, project and invoicing management tools, integrated Google and Yahoo sign-ins, allowing users to sign into Zoho using a Google or Yahoo account. Today, Zoho is launching sign-in integration with Google Apps, letting users login to Zoho using their Google Apps credentials.

Read More…