We've added Zendesk to the list of applications that Tracker integrates with. Zendesk is a "beautifully simple", on demand customer support help desk system. This integration allows your development team to prioritize and collaborate around Zendesk tickets as linked Tracker stories, bringing development and support closer together in your organization.

To learn how to set up Zendesk integration for your project, visit the integrations help page. Once enabled, you'll see a new panel in your project, allowing you to see and drag/drop Zendek tickets into the backlog or icebox. Story comments and state changes will appear in the corresponding Zendesk ticket as comments.

Note: At the moment, the Pivotal Tracker target in Zendesk does not create linked stories in Tracker. We're working with Zendesk to enable that, and make the two integrations seamless.

Jim Highsmith introduced the Agile Triangle, creating a new triangle to reflect Agile development practices, moving beyond the traditional Project Management Triangle (a.k.a. the “Iron Triangle”):

Figure from Agile Project Management: Creating Innovative Products (2nd Edition)

I don’t disagree with the concepts that Jim Highsmith puts forth with his Agile Triangle at all. He’s advocating that Agile projects should be measured against delivering value to customers, doing so with quality, using constraints as important project parameters, but not the goal.

However, the inclusion of the Project Management Triangle as a dimension of the Agile Triangle bothered me from the outset. My main concern is that there are distinct differences between how traditional project management and Agile projects are approached.

The constraints of the traditional Project Management Triangle are important because traditional project management is geared towards achieving predictability in one of these dimensions. And when one dimension changes, and another dimension is affected; the constraints are interrelated.

And while the Project Management Triangle models the key constraints associated with predictability, it does not attempt to describe everything that goes into making a project successful. Entire books have been written about what goes into achieving success in a software project, and the Project Management Triangle is always a part of that equation. The point is that it is that the Project Management Triangle is by no means the entire picture.

As I thought more about it, I began to struggle with the Value and Quality dimensions of the Agile Triangle as well. Yes, Agile methodologies focus on delivering value and quality, but any project wants these, regardless of the methodology used. I ultimately ruled out Value and Quality as proper dimensions of an Agile Triangle.

Since being a critic is easy, I felt that if I disagreed with the Agile Triangle, I should put some thought into what I feel is an appropriate Agile Triangle. For me, it came down to a question of focus and emphasis.

Agile development is all about expecting, embracing, and responding to change. Agile is about people over process, and placing trust in those people to produce results. Agile also recognizes that software development is learning.

I therefore focused my Alternative Agile Triangle as a model of adaptability and productivity achieved through people:


Learning
Agile development embraces continuous learning, such as learning about the true business needs through frequent dialog, inspection and adaptation of delivered software. Retrospectives are another way learning takes place: the team reviews what works well and what can be improved.

Empowerment
Empowerment is the trust and granting of authority so that the team can act independently. One benefit is that the team will embrace change because they are closely involved with the change – either through the business discussing the need for change with the team or the team initiating change themselves as part of a retrospective, where they collectively determine what change is needed so that they can improve.

Another benefit of empowerment is the speed at which problems can be solved. As a manager, I can’t be everywhere and solve every problem. By trusting people to put their brains together to solve a problem, a situation won’t linger until I can get around to it – it can be resolved immediately by those who have the knowledge and experience to make the call. There will still be exceptions, naturally, but the goal is to place the trust and authority for making calls about their work in those who know the most about the work.

Competency
Competency concentrates on the knowledge and skills of the people, another important dimension to Agile development. This favors “individuals and interactions over processes and tools”, to quote from the Agile Manifesto. Both individuals and teams must be competent in order to embrace change and improve the productivity of the team.

Because of the highly collaborative, self-directed nature of Agile teams, people must have both technical and interpersonal skills. Ultimately, teams must function as more than a collection of individuals working on project tasks; effective collaboration is a sharing of knowledge, skills, and the willingness and ability to hold each other accountable.

Each Dimension Affects the Other. Learning affects competency. The more you learn from both project work and professional development outside of project work, the more competent you become.

Competency is affected when a manager fails to truly empower the team or fails to guide a team towards an empowered state. People certainly won’t strive to learn as much in environments where someone else is calling the shots and controlling every aspect of the job.

Competency can affect empowerment. If individuals and teams aren't fully prepared to operate independently due to deficiencies in their technical expertise or ability to self-organize, they will require more direction and coaching versus operating in a hands-off, fully-empowered mode.

Ultimately, highly competent teams learn faster and can embrace and respond to more change than less capable teams – and they will likely want to introduce change at a faster rate in order to continually improve.

I’m sure that you can think of other scenarios. The key is, I feel that the dimensions of the Alternative Agile Triangle are both interrelated and reflect the spirit of Agile development.

What about the Project Management Triangle?
The traditional Project Management Triangle can stand on its own. It's useful for non-Agile projects, and it is certainly a great tool to use when considering and explaining trade-off decisions, like why everything can't be a priority, even with Agile projects.

In the end, Agile development approaches projects differently, and that is what should be emphasized.

The Alternative Agile Triangle is about the people and their ability to embrace and respond to change whereas the Project Management Triangle is about planning, constraints, and predictability; accommodating change through altering one of its constraints.

Measurements in Agile should be focused on the people and teams, the knowledge, skills, and abilities of people and things that they need to do in order to produce results. As Jim Highsmith stated, “… it’s much better to have fuzzy measures of really important things that precise measures of less important things.” I’ll cover more on measurements in a future post.

I’ve outlined my opinion about the Agile Triangle and presented an alternative. After reading this, what is your opinion?

Each year the Eclipse Foundation holds an election to vote in board representatives for its committers and sustaining members. If you represent one of these member classes you have one week from today to cast your vote. I’m running as a sustaining member representative and my vision is below. Voting uses a single transferrable voting system, so be sure to read other candidates’ positions before voting.

Vision

Eclipse has reached a stage of maturity that enables Sustaining Members to play a primary role in driving the direction of Eclipse. As Sustaining Members, we represent the largest volume of the Eclipse membership. In 2010 our impact on Eclipse and the value we receive from participating are poised for substantial growth.

I’ve been closely engaged with both the technology and the business aspects of the Eclipse ecosystem since the outset in 2001. I’ve worked directly with many Solution Member companies and watched some Eclipse business models flourish while others have failed. Starting a successful company around Eclipse has given me a pragmatic perspective on how to participate in the platform while growing both product and service revenues on Eclipse-based offerings. As a Sustaining Member representative, my duty will be to apply that knowledge to help make your Eclipse-based efforts successful.

Succeeding in Eclipse means striking a balance between the member, committer and user communities. As board representative, my priorities will be to:

  Facilitate reaching users: Marketing in a vendor-neutral open source ecosystem can be far from obvious, and reaching the very broad Eclipse user base is needed for both the commercial success of members and of Eclipse as a whole. I have been closely involved in improving the install story for Eclipse solutions and the upcoming Eclipse Marketplace client. These efforts will provide the next generation of opportunities to get your solution into Eclipse users’ hands.   Lower the barrier to engaging with projects: With product releases and other pressures, too often the step of getting directly involved with an Eclipse project that you build on does not make the cost/benefit cut. But not getting involved has the longer-term cost of incompatibilities and overhead. Lowering the bar for direct participation will provide members with better access to the collaboration and contributor community that make Eclipse a great open source ecosystem. On the Mylyn project we have had over 800 bugs and feature requests resolved by community contributions. I will use my experience of making this work for Mylyn to help lower the overhead of participation with existing projects so that similar benefits are accessible to more members.   Listen to members: My job will be to represent your needs on the board, and I will work with the other representatives to actively seek out feedback from all Solution Members. I helped make the needs of individual committers heard as a committer representative on the Eclipse board, and will ensure that your needs are
represented in discussions and decisions made at the board level.

About the candidate

Dr. Mik Kersten is the CEO of Tasktop Technologies and lead of the Eclipse Mylyn project. Mik is a popular speaker on Eclipse at conferences in the United States, Germany, and worldwide. Highlights of Mik’s contributions to Eclipse include:

  Creator and lead of the Eclipse Mylyn project (since 2005)   Active member of the Eclipse Architecture Council (since 2007)   Elected committer representative on the Eclipse Board of Directors in (2008/2009)   Only Eclipse evangelist to be voted a JavaOne Rock Star (2008 and 2009)   Only Eclipse content author on the top authors of the decade list of IBM developerWorks Java   PhD in Computer Science from the University of British Columbia that lead to the invention of Mylyn’s task-focused interface (2006)   Co-creator of the Eclipse AspectJ and AJDT projects (2002) based on his work creating of the first Aspect-Oriented Programming (AOP) tools, Xerox PARC (2000)

Related publications

  Symbian Blog: Mik Kersten on Transparency   Tasktop Blog: Growing open source ecosystems: the install story   Tasktop Blog: Tasktop working with Microsoft to improve Eclipse on Windows 7   How Software is Built: Interview with Mik Kersten (highest ranked in series)   Tasktop Blog: Tips on paying for free software   Tasktop Blog: Platform for Innovation, Part 1: Openness & Modularity

Read more about Mik Kersten on Wikipedia.

Be more productive. Guaranteed.

I read an interesting analysis comparing the permission settings of Facebook and MySpace and how the permissioning impacts

• the type of information people share and
• the adoption of the websites.

The article makes the point that people feel comfortable sharing meaningful information on Facebook because it has more controlled and tighter permissioning than MySpace. It also states that this is one of the secrets behind the increased adoption of Facebook.

Facebook, the article continues, has an “exclusive” feel, like a club or fraternity. You can decide your circle of friends and therefore who gets to see the information you post.  Because you can control the connections, you are comfortable sharing meaningful information. Because the information remains meaningful, you keep coming back to the website.

MySpace has the feel of almost any place on the web. It is less exclusive. Information posted on MySpace can be seen by a wider audience. This openness, the article points out, leads to people posting less meaningful information, fewer discussions and, ultimately, less participation by each person.

ROLES IN A PROJECT

People’s roles in a project are defined. They may be defined by the project plan, by a person’s skillset, an organizational chart or the formal relationship among the project team.  The connections are not made in public, as it were.  There is a relationship in place.

Good project management software (like Vertabase) can map these roles into specific access levels and leverage those roles to improve projects.

Like with Facebook, you can increase the value of the information shared on projects by

• defining the type of information people can share
• controlling who gets to see that information and
• defining how that information is shared.

This will drive adoption of the project management software as a whole, and keep ongoing participation in projects high.

I am always suprised when I see old or misinformation floating around about SEER for Software (SEER-SEM).  I recently saw a presentation (not one of ours) where it was stated that SEER continues to reduce effort…to the point of absurdity when the schedule is stretched unreasonably long.  SEER deals with minimum time, optimal schedule, and sub-optimal schedule.

Of course there is a point where the ineffeciencies of elongated schedule cause people to gold plate, etc.  And SEER for Software does start increasing costs when that point is reached.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related Posts Computer Generated

• Eating the IT Elephant: Moving From Greenfield to Brownfield Development
• Earned Value Analysis Without An Achievable Plan Is Futile
• Brooks Law Is Applicable To Many Collaborative People Activities

In addition to the webinar Bob Hunt will give on Acquisition Reform, the history  interview by Dr. McNichol is definitely worth a read.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related Posts Computer Generated

• Acquisition Reform (WSARA) Webinar Discusses Lessons Learned and Way Forward

Thanks to Galorath’s Sam Sanchez for these insights on non-technical parameters:

When I first started with Galorath, I used to wonder about the usefulness of having parameter inputs like “Developer Experience” or “Development Tools and Practices” within our electronic models.  Like many engineers, I didn’t like these types of qualitative inputs, preferring to use more concrete entries like “frequency of board,” “number of ICs/IO” and others. However, as the years have progressed, I am amazed at how critical these qualitative parameters continue to be. Like I heard mentioned in one of my SEER H classes, “There are A teams, B teams and believe it or not even D teams.” More importantly, the impact of these variations can cause dramatic differences in a project’s level of effort.

Common reasons for poor team efficiency could be longevity of the individuals in the given technologies, recent mergers, bad chemistry, poor communication practices and others. It’s important to note that we look at this parameter as an overall assessment of the team.

To help reduce confusion with this input, SEER-IC looks at the following criteria: Accomplishment Metric, Configuration Control, Communications, Adv Skills and Tool Experience. Specific measures within these major sections help users to come up with a reasonable range input. Also, this is definitely one parameter that should have a different entry for “least,”, “likely” or “most.”  In other words, there is always some level of risk here.

In SEER-H, swings in Development Experience individually can swing costs by as much as 30%. Development  Tools and Practices by as much as 50%. We tend to look at “common” variations. In reality, at times, the variations may be orders of magnitude.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related Posts Computer Generated

• SEER-IC Add-on To SEER-H Gets The Newest Technologies
• SEER-H Expanded Technology Support for Electro Optical Sensors
• SEER Quantifies Savings On Military FPGAs (Custom Chips)
• SEER for Hardware, Electronics and Systems: Major Enhancements
• New Update To SEER for Hardware, Electronics & Systems Hits Beta

If you are interested in government acquisition reform be sure to register for this webinar.  Bob Hunt, Galorath VP of Services, was a senior Pentagon official the last time around and will share both what was learned from before and how to apply these to the current WSARA (Weapons System Acquisition Reform Act).  Here is the webinar invitation.

Acquisition Reform (WSARA) And How It Impacts Your Estimations: Looking Forward And Lessons Learned

Weapons systems acquisition reform has been a recurring topic within the Department of Defense for many years. 

Mr. Bob Hunt, Galorath’s V.P. of Professional Services, was a Senior Pentagon official during the previous Acquisition Reform  initiatives.  He has since been active in the contractor community.  Mr. Hunt will offer a unique perspective on how these acquisition reforms will impact both the Government and the contractor estimating communities.

This WebEx will discuss the unique implications of the latest reform on the cost and schedule estimating process, including:

•          Cost Assessment & Program Evaluation

•          Directors of DT&E and Systems Engineering Performance Assessments & Root Cause Analysis

•          Assessment of Technology Maturity

•          Trade-Offs in Cost, Schedule and Performance

•          Critical Cost Growth in MDAPs

•          Earned Value Management

•          Required Reports

•          Cost Assessment & Program Evaluation

•        How some of the SEER applications can be advantageously applied for Pre-milestone A estimates 

•          And much more!

Much (or some) of this has been tried before, e.g. Goldwater-Nichols Department of Defense Reorganization Act of 1986; also discussed in “The Cost Analysis Improvement Group: A History”  by Srull, Margolis, and McNicol.  WSARA is being driven by the continued and “sometimes surprising growth” in the cost and schedule of Major Defense Acquisition Programs (MDAPs).
——————————————————-
Date and Time
——————————————————-
March 9, 2010
8:30 am, Pacific Standard Time (GMT -07:00, San Francisco)
11:30 am, Eastern Standard Time (GMT -05:00, New York)
4:30 pm, London, England 

——————————————————-
Presenter
——————————————————-
Bob HuntVP of Services, Galorath Incorporated

——————————————————-
To register for the online event
——————————————————-

This complimentary event requires registration with a corporate email address.

1. Go to https://galorathevents.webex.com/galorathevents/onstage/g.php?t=a&d=669660618
2. Click “Register”.
3. On the registration form, enter your information and then click “Submit”.

Once the host approves your enrollment, you will receive a confirmation email message with instructions on how to join the event 

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related Posts Computer Generated

• Step Ten: Track Project throughout Development
• Step Nine: Document Estimate and Lessons Learned
• Software as a Service vs. Service Oriented Architecture vs. Cloud Computing
• Make or Break: Why Accurate Cost Estimation Is Key
• Estimate Packaged Software Or Suffer the Consequences

Congratulations to Dr. Luke Min, who heads Galorath global efforts in Korea, for his being made an INCOSE  Fellow.  This quote from his letter follows:

“I am delighted to confirm your election as an INCOSE Fellow, effective immediately. You join a distinguished group of, now, 62 individuals whose contributions to the art and practice of Systems Engineering are recognised and respected worldwide.

By providing intellectual leadership to the discipline as a whole and enhancing the INCOSE organisation through your support to the Board of Directors and other leaders, INCOSE Fellows have the ability and opportunity to contribute significantly to the INCOSE mission to “Share, promote and advance the best of systems engineering from across the globe for the benefit of humanity and the planet”. I hope that as a new INCOSE Fellow you will both benefit from this honour and embrace the responsibilities that it brings, continuing to engage in the advancement of INCOSE and the discipline, and leading by example to improve the professional standing of all those who practise systems engineering.”

I have known Dr. Min for a number of years and have seen, first hand, his contributions to the industry.  Again, congratulations, Luke.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Since we all use the term “knowledge worker” these days. I thought I would take some time to define just what I believe a knowledge worker is. Before reading on, take a stab at defining a knowledge worker for yourself. I’d be interested in any thoughts that you may have...

Let’s start by defining knowledge itself, which sits on top of a pyramid:


Data (or the seldom-used plural, datum) is a factual entity that sits at the lowest level, and is obtained through techniques such as measurement or observation. Information and knowledge are derived from data. For example, collecting data about automobile drivers such as their ages, sex, number of accidents provides the inputs that can be examined and turned into useful information.

Information is about examining the data (facts) and attaching meaning to the data. Examining multiple data points may reveal some type of pattern that gives form to the data; in effect, information becomes a representation and communication mechanism of the underlying data.

Continuing with the automobile driver example, analysis of the data reveals that young male drivers have a higher risk of getting into an accident than anyone else. The statistical observation attaches meaning to data obtained about drivers and their accident rates and becomes information – and input – used by insurance companies in determining how much to charge someone for automobile insurance.

Knowledge is the accumulation of information, experience, and reasoning about a particular subject or field. Knowledge coupled with skills and abilities becomes expertise. (Wisdom is a variant of knowledge, where the deepest level of insight is attained, in my opinion.)

There will be differences in expertise between individuals, as some people obtain a greater understanding of their field than others in the same field. Even where expertise is equivalent, there can be differences in opinion because each person has different experiences, preferences, and values. Back to the automobile drivers one more time, knowledge is used to actually determine how much to charge different drivers, as represented by their risk. As you may have noticed, no two insurance companies charge exactly the same rate for automobile insurance.

Now that knowledge is explained, it is an easy step to define a knowledge worker: Someone who engages in the active application of knowledge to achieve a specific purpose, or someone who initiates a new data-information cycle to generate new knowledge – advancing their field. A knowledge worker applies existing knowledge or develops new knowledge.

Knowledge work is not routine. Knowledge work can involve analysis, strategizing, planning, prioritizing, brainstorming, critical thinking, or creating. Knowledge work is about dealing with difficult situations that cannot be directly addressed through pre-defined solutions.

Software development falls into this category. Writing software is not about building the same application over and over again. There is uniqueness involved every time.

Routine work can be handed off (ideally) to a computer. Referring back to the automobile insurance scenario, many times it is a routine decision for an insurance company to insure someone. Standard questions can be placed on a web site, and based on the answers to those questions a decision can be made (paraphrasing William Shakespeare’s Hamlet) “to insure or not to insure…” – along with determining how much it will cost to insure someone – by pre-programmed logic. Exception conditions outside the norm can be forwarded to an underwriter for analysis and a decision.

Challenges with Knowledge Work
Knowledge has value and this value will decrease over time. The world is continually changing, and information is being generated and circulated at a phenomenal rate. Knowledge that is pertinent and relevant today may be of little value five years from now.

In general, keeping relevant (knowledgeable and valuable) over time requires continual learning, reflection, adaption, and application of new knowledge. This places a demand and challenge on knowledge workers to manage their time to provide for learning and growing. “Maintaining” in the knowledge arena is effectively taking steps backward. The world will move past you.

All knowledge is not easily captured. Some things can be captured and written down in a form that is understandable to others. An insurance company deciding what questions to ask and what calculations will be performed to determine a premium is an example. This is “routine knowledge” (once it is created) that can be captured and used repeatedly by less knowledgeable people.

Some knowledge – tacit knowledge – is more of a challenge. You can capture instructions about how to ride a bike, but reading about riding a bike will not enable you to immediately ride a bike the first time that you try. Book-learning can be like that as well. You might understand the concepts, but the author has different experiences and values than you do. The truth is that you might need to get some personal experience under your belt to truly understand and value some of the concepts that an author conveyed.

This is also why “knowledge transfers” in organizations can be challenging. If you expect that a one or two-day “knowledge transfer” will fully prepare someone to fill another’s shoes in exactly the same way, you will be dissapointed. In fact (and since this is a blog about managing software development), software development is effectively a knowledge transfer exercise.

The goal is to translate business knowledge into software. This requires a collaborative effort to represent the business in a very precise, step-by-step processing of instructions to conduct business transactions on a computer. This collaborative effort alone is a challenge, as those on the business side do not understand computers as deeply as those who write the software, and those who write the software do not understand the business as deeply as those involved with the business.

And there is another problem that lurks with software: The knowledge – expertise, values, and experience – of the few business representatives involved with software projects often speaks for the many. The big question is: What are the odds that the judgment of those few will be correct?

This is why building software in small increments is valuable. It allows the software to be viewed by many early and often. Soliciting of feedback allows course-corrections; better to set a course and make small adjustments along the way than to sail directly into rocky waters – where you will sink – because you wanted to maintain your original course come hell or high water.

If you're looking for another (humorous) perspective, blogger Steve Schwartz has a great post about The 3 Types of Knowledge.

Seth Godin’s post from today trash talks compliance, in favor of teaching initiative and intelligent problem solving. Surprising to many, I’d like to speak up in defence of compliance.

There is incredible value in compliance.

It is valuable for a person to be able to follow a plan and consistently perform. 

It is valuable for an organization to have people who can follow plans and perform consistently. 

To grow, an organization needs to be able do what it does, consistently.  It needs to be able to teach and train people to be part of doing it. That’s the value of process and project management.  

1. A process or plan is developed, then executed.
2. The work product is evaluated and;
3. The plan is evaluated and improved. 

The goal of management, as a field of study, is to get people with different skill sets to work together to produce remarkable results.  Compliance helps managers accomplish this goal, measure results and rework.

Be consistent, evaluate results and rework.

Seth often talks about consistency and plugging away at building a brand or product. Rare are the overnight successes and instant home runs. A much more sure path to success is to focus on base hits. Be consistent, evaluate results and rework. You can’t do that if people don’t follow the plan.

Note: this post is going to be a bit of a cheese-fest. Consider yourself warned.

Jason Carlson visiting SpaceX corporation.Yesterday, our CTO Jason Carlson and I were lucky enough to be able to visit one of our favorite customers, SpaceX Corporation, at their headquarters in Hawthorne, CA. SpaceX is one of our biggest installations, and the purpose of the visit was to hear and see first-hand what using LiquidPlanner is like for larger teams.

We didn’t go down looking for pats on the back; we wanted to hear about pain points, feature requests, areas of confusion, and challenges to adoption. We got, them, too. The SpaceX team’s projects are hugely complex (they’re building rockets, after all), comprised of nearly 6,000 tasks. On top of it, they’ve got nearly 2,500 dependencies in the system. This creates some slowness in load times (many of which are browser-based rendering issues). It also calls for easier batch updates (or in-line editing), better dependency debugging, more permission controls, and an easier way of keeping the workspace “clean.”

You can be sure that Jason and I took copious notes. Naturally, these feature requests were mostly ones we’ve already documented and plan to work on as quickly as possible. Not just for the SpaceX team, but for the hundreds of companies like them that would benefit from such improvements. As part of our iterative design process, this is par for the course. Build, correct, improve, repeat. We’re excited to get started.

Thanks to the SpaceX team for taking the time out of their busy schedules to spend the day with us. (As a bonus, we did get a tour of their amazing facility and got to see some of their launch vehicles in various stages of production. Probably one of the most awe-inspiring experiences of my life.)

The interior of Kenny's cab.And here’s where Kenny comes in. The very kind receptionist at SpaceX called us a cab to get us back to LAX for the trip home. The cab that picked us up was like none I’ve ever been in before. The interior walls were covered completely with photos of Kenny the driver’s “regulars” – thousands of them. Kenny called the people in the pictures his “children.” The cab was hung with tiny sparkling lights and little inspirational sayings. The back of the front driver and passenger seats were hung with laminated copies of press coverage Kenny’s received. Apparently, he’s somewhat of a legend in Southern California.

One of the sayings posted in Kenny’s cab struck me: “I’m not just a cab driver, I’m a friend who wants to make sure you get home safely.” Really, what more can you ask for in a service provider?

Although we don’t post it on our website, the team at LiquidPlanner operates under the same philosophy. (“We’re not just software developers, we’re friends who want to help you manage your projects successfully.”) I know that sounds silly, but I can remember almost every customer I’ve worked with – what company they work for, where it’s based, and what challenges they face. The reason we do what we do is not that project management software itself is so mind-blowingly exciting. It’s that there are real teams, real people, that need a tool to make their lives better. They’re our “regulars.” They’re the motivation for every line of code we write.

So we may not have achieved the legendary status of Kenny the Cab Driver (yet!), but if we can help our regulars the way he does his, we will have done our jobs.

From an email I received from Frontrange Solutions looking at tradeoffs of internal versus SaaS.

“Though many are jumping on the on-demand bandwagon, many are also jumping off.  Churn rates for on-demand are as high as 30 percent while renewal rates with on-premise software stand in the 80 percent range. There must be a reason an increasing number of organizations that tried on-demand applications have returned to an on-premise solution.  For reasons such as:

•  total cost of ownership
• ease of customization
• control of data
• process automation options
• user-interface
• disaster recovery

What this doesn’t seem to show is whether those who drop out of SaaS go to an internal solution or just stop doing that SaaS function.  This needs more study.

After the recent disaster where the building where we host our mission critical applications (with its backup generators, etc)  was without electricity for two days, we are actually investigating getting our email and other functions out onto a data center ourselves.  It is more expensive since we have already invested in infrastructure and IT services.  But it may be worthwhile for disaster recovery.  Of course the questions of what if the data center has a disaster itself, how do we keep long term backups, etc. are still unanswered.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Related Posts Computer Generated

• Don’t Assume SaaS Is Cheaper
• Software as a Service vs. Service Oriented Architecture vs. Cloud Computing
• How Galorath Quantified the Salesforce.com Platform With SEER For Software (SEER-SEM)
• 90% of Companies Surveyed Increasing Software as a Service (SAAS)

The Mylyn JIRA Connector has been developed as part of the Eclipse Mylyn project since 2006 (Bug 109905), when Wesley Coelho and I met in a Vancouver coffee shop and decided to start collaborating on an idea for a startup that involved extending Mylyn’s open source integrations to commercial tools. A year later Wesley became one of the first employees at a new company called Tasktop Technologies, the connector took off, saw steady community contributions, and Mylyn’s reach was extended to JIRA users. Later in 2007 we kicked off a collaboration with Atlassian to improve the JIRA Connector, which in 2008/09 led to Tasktop working with Atlassian to create the initial Atlassian Bamboo and Crucible connectors, now part of the Atlassian Connector for Eclipse effort hosted on studio.atlassian.com. The time has come to merge the two codebases of Atlassian’s Eclipse integrations, and Atlassian has asked that the JIRA connector move to studio.atlassian.com.

According to Atlassian, the decision migrate the source code to their own infrastructure was driven by a desire for greater operational efficiency. Both the implementation of the Connector for Eclipse and the APIs in Atlassian’s server products are evolving, and hosting all these projects in a unified infrastructure enables faster development and more frequent releases of new and improved functionality. The Atlassian Connector for Eclipse will continue to be open source and distributed under the EPL. Anyone can view full project activity and download the full source at https://studio.atlassian.com/browse/PLE. Currently, all committers to the Atlassian Connector for Eclipse are either Atlassian or Tasktop employees, but Atlassian is working to allow others to commit new functionality to the code base.

Mylyn has grown from two integrations to over four dozen, and is playing a driving role in developers’ adoption of Application Lifecycle Management (ALM) and Agile collaboration tools. Having a connector hosted as part of the Mylyn project used to be vital due to the friction of finding and installing Eclipse extensions, and the JIRA connector got very broad exposure. But with our introduction of the Mylyn Connector Discovery feature in last year’s Eclipse Galileo release, it became trivial for users to install Mylyn connectors wherever they are hosted. Also thanks to the discovery mechanism, the move will be transparent to users of the integration.

For users of Tasktop and Mylyn, the main concern is the availability of a high-quality connector. One of the most important aspects of Mylyn’s architecture is that it provides a unified user experience across all integrations, since the majority of the user interaction is handled by the Mylyn framework. Atlassian has provided assurance that they will contribute to the Mylyn framework as part of increasing their own resources behind the integration, which will help ensure that the integration evolves along with upcoming changes in Mylyn. An expected benefit of the move is that some of the shortcomings of the integration that stem from JIRA’s SOAP APIs, such as the lack of support for custom fields and workflows, will be addressed more quickly with all of the code hosted and supported under one umbrella. Tasktop’s relationship with Atlassian continues, and the JIRA connector remains part of the Tasktop Certified program that ensures usability and ALM stack interoperability.

Mylyn’s goal is to provide a framework for Eclipse ALM integrations and to support an ecosystem of extensions. To that end, we have aimed from the start to provide reference integrations to open source tools, starting with Bugzilla. The JIRA integration was the exception as JIRA is closed source, but has been very popular with open source developers due its use in some open source communities such as Apache. The move of the JIRA connector restores the clear split between Mylyn’s reference integrations to open source repositories, hosted on eclipse.org/mylyn and the very the broad ecosystem of integrations with closed source tools. This will help focus the resources of the project on the core framework and open source integrations, while mechanisms such as Connector Discovery and the Tasktop Certified program ensure easy installation and the quality of the connectors that developers need to get the most out of Mylyn.

Be more productive. Guaranteed.

There are few things more frustrating to a project manager than team members who do not communicate. Non-communicators can single-handedly eliminate a manager’s visibility on a project and be a source of unforeseen, and therefore, uncontrollable risks.

Within this group, the most frustrating are those that ignore direct requests for information or who only talk when they feel like it.

• To the extent that a project manager can pick their own team, non-communicators are generally the last people picked.
• To the extent that a project manager can influence HR decisions, “better communication skills” is the area of improvement most often recommended for non-communicators.
• To the extent that a project manager can limit a non-communicator’s participation in a project, they will.

But when it can’t be avoided here are a few tips to managing a non-communicator on a project.

Find the communication medium that works best. Some people respond to phone calls, others to emails. Some respond to instant message and some prefer talking one on one. Find the medium that works best for that person and stick to it.

Experiment with Non-Traditional Ways of Communicating. All of the above mentioned media are conversations or openings for a dialog. They are in a question/answer or solicitation/response format. Some people simply don’t work that way. Get creative in finding other ways of getting information that don’t involve a “conversation.”

For example, I’ve worked with non-communicators who are best at giving information as it directly relates to the completion status of a task. Instead of asking how things are going, I’ve found it more valuable to assign a task in a project management tool and let them indicate its status. The options I set in the project management software are simple: done or not-done. To maximize the value of information from this technique start with the most detailed level of a task you can find. Think of it like 20 questions where the person can only answer yes or no. Make each question (or in this case, task) count.

Be Patient. People have their own time lines when it comes to answering questions. Don’t mistakenly categorize someone as a non-communicator just because they take a long time to respond to you. I know some people that take 10 minutes or more to respond to a question on instant message. It can be very frustrating when you are expecting an “instant” answer on “instant message” and instead, get a response 10 minutes later.

Sometimes, people are thinking about the answer. Other times, the answer might be more complicated than the asker thinks. Learn how long it takes people to respond and budget in the appropriate amount of time.

Know How to Get Information When You Absolutely Need It. The corollary to being patient is to have a clear way to get information in an emergency. For example, call the person on their cell phone or go directly to their desk. This requires that the project manager prioritize their information need or, at a minimum, have a clear understanding of when to really bother someone. To be effective, use emergency procedures sparingly or, like the boy who cried wolf, it becomes just one more thing the non-communicator doesn’t respond to.

Be Persistent and Consistent. Make sure you get answers to the critical questions you ask. Make it easy for a non-communicator to distinguish between hearing your communication and needing to participate in the communication by providing information.

In the best case, by finding ways to get the information you need from a non-communicator you can potentially find a new, more productive way to make use of their skills on your projects. And if that doesn’t happen, you can at least reduce unforeseen risks to your projects and increase visibility.

Behind the Cloud: The Untold Story of How Salesforce.com Went from Idea to Billion-Dollar Company-and Revolutionized an Industry by Marc Benioff and Carlye Adler

Since I work for a software company, I was very interested in the story of Salesforce.com and how they built their application and company. As the book points out, Salesforce.com sought to build an industry – what is now SaaS (Software as a Service) – something that they certainly took the lead on over the past decade with great success. Salesforce.com has a mini-industry built around its product and platform.

The book is an excellent blend of advice that is provided as plays (think sports playbook) with the story of Salesforce.com woven in. The writing is excellent, and you can really feel Marc’s enthusiasm and pride at how he steered the company from its inception to its present-day success.

The journey can be gleaned as you read through the various playbooks that comprise the book:

The Start-up Playbook
The Marketing Playbook
The Events Playbook
The Sales Playbook
The Technology Playbook
The Corporate Philanthropy Playbook
The Global Playbook
The Finance Playbook

Marc comes across as daring and unconventional, particularly in his marketing approach – such as staging a “protest” at a competitor event. Marc is very willing to go after the market leader, stating in Play #22: “Engage the market leader. By their defending themselves against you, they acknowledge you and begin to chip away at their own airtime.”

Marc had a vision and courage from the outset, and that was to build a hosted model that did not require customers to install and configure expensive software, which was not something everyone bought into. As he noted in Play #52, venture capitalists argued for him to build a hosted model to lure small businesses AND an in-house package that would be similar to other companies in the CRM space.

Marc and Salesforce.com said “No.” They felt that their SaaS model would never work if they hedged their bets. Marc also explicitly stated this in one of his plays – Play #13: “Be willing to take a risk – No hedging.”

I completely agree with this, and I’m sure others will as well, including Andy Grove of Intel. As I noted in my post Are you Committing Your Business Tanks?, Andy Grove has stated: “Hedging is expensive and dilutes commitment.” And without commitment, Andy says, “You will always be looking for a way out rather than a way to win.”

Marc, in Play #20 continued his daring advice, stating: “Always, always go after Goliath” – positioning yourself in the role of underdog and visionary. This is dangerous advice without considering the greater context of the Salesforce.com story.

It is NOT a great idea to take on an established competitor head-to-head; if Salesforce.com created yet-another CRM in-house enterprise product like the venture capitalists suggested, they would have been hammered by the competition. It would be been extraordinarily difficult to differentiate Salesforce.com against other established competitors.

Fortunately, Marc is big on differentiation, and he did what The Innovator's Solution: Creating and Sustaining Successful Growth by Clayton M. Christensen, Michael E. Raynor suggest: Salesforce.com disrupted the incumbent players and went where they did not want to – or could not easily – go. Salesforce.com created a fully hosted application using a subscription model that was fundamentally different than the competition's locally installed, in-house software that was purchased in full up front.

The market leaders didn’t initially believe in this model and did not want to participate in that fashion. It was only after Salesforce.com had begun to establish itself that the competition reacted, and they responded by making strides to deliver their software in the same way.

The book tended to reinforce other concepts that successful companies espouse: hire and retain great people, treat your customers well and learn from them, and adapt your company as you go. Overall, the book offers a great deal of insight about business success in general, and Marc’s flair and enthusiasm make the book both informative and entertaining.

I highly recommend the book, but don’t be fooled by the title; you won’t learn anything about cloud computing, but you will learn about and understand how the Salesforce.com cloud was formed and grown.

Peter H. Feiler and Jorgen Hansson from the Software Engineering Institute (SEI) have compiled and published some interesting statistics that point to the benefit of finding and fixing bugs early in a software development project.

There is a huge benefit to finding and fixing problems early.

Here are some of the most remarkable findings:

• 70% of faults are introduced in the early stages of a project lifecycle.
• But, only 3.5% of faults are found at that stage.

• 80% of faults are actually only found in the later stages of a project’s lifecycle.

• The cost of fixing faults in the early stages is 2.5x.
• The cost of fixing faults in later stages is 16x or higher.

According to the research you can save yourself over 600% on repair and rework costs on a project by finding and fixing problems early.

While this data is specifically for software development, the conclusion rings true for projects of all sorts, including marketing projects, creative work, manufacturing or research projects.

When you have developers that can do anything, it’s hard not to do everything. It can be a mental leap to consider a service for something you think you can build yourself.  

But one day you grow up and realize running a successful business means making the most out of your team’s precious work hours.  

This is the true story of such an awakening for our team and our big switch to Squarespace, a "Software as a Service" provider that enables you to design, build, and host a website...

Wanted to pass on some great feedback from a new Vertabase customer and their first-hand experience using the timesheets on the iPhone.

Feedback has been positive so far with regards to how simple and easy the system is to use. I even tested timesheet entry using Safari and our iPhones and it works great. I looked at many web-only timesheet/project management products and Vertabase has exceeded my expectations so far.

The company is a strategic marketing and research firm.

There are some distinct changes managers need to make if they plan to be successful in the 21st century. To put it simply and directly: Techniques that worked well in the 20th century will not continue to work well in the 21st century.

The roots of 20th century management lie in manufacturing where the work was more manual and the output well-defined. In today’s business world, we’re dealing with much more difficult problems where a problem statement exists and someone must come up with a solution. The output is not well-defined at the outset, it is shaped as a function of the work. In addition, knowledge workers typically have a greater understanding of their work than their manager does.

This places very different demands and expectations on a manager. Some people even feel that this makes managers are obsolete, but I beg to differ. Good managers have the knowledge, abilities, and experiences that can help individuals and teams achieve the high-performance state that we all want them to reach. The focus of management needs to change to meet today’s needs.

“Getting things done through others” needs to change to “developing people and teams.”

“Getting things done through others” is a traditional definition of management, and one that I’ve used myself. However, it implies a command-and-control scenario whereby a manager assigns tasks directly, and where the manager is ultimately responsible for the achievements (or lack thereof) of the team. Empowered, self-directed teams do not need a manager explicitly assigning tasks; the team can collaborate to accomplish the work, and they can be responsible for the results.

The raises the ante on team members as the teams take on what has been the traditional purview of management, such as planning, problem solving, and decision-making. There is also a need for improving communication skills – something else that good managers are very skilled at. A 21st century manager should assess and coach teams (and individuals) in these areas so that the teams are executing well to maximize effectiveness.

The 21st century manager should also help identify training and career opportunities for individuals on teams. Facilitating the learning and growing of employees is an essential role; keeping an employee challenged and growing in his or her career will provide a great deal of satisfaction, engagement, and loyalty – essential to retention.

“People under your thumb” needs to change to “finger on the pulse.”

Since individuals and teams will no longer be doing a manager’s bidding, a manager’s role will shift to that of someone who is in touch with what is going on, allowing autonomy and being supportive through working with individuals and teams to understand what is working well and what the impediments are.

Skilled managers understand the strengths, weaknesses, and preferences of those who report to them, and can even assess the dynamics and flow of a team – good or bad – to judge whether changes are necessary, and what changes need to be made. A good 21st century manager should be able to intervene (when required) and remove a poorly performing team member or assist in activities like lining up a specialist that can help the team overcome a specific problem that is outside of the expertise of anyone on the team.

Ensuring compliance needs to change to  facilitating engagement.

Traditional management has been about being specific about the work, and setting down rules and procedures to ensure that the work happened as planned, using the typical “carrot and stick” approach to reward favorable results and punish poor results.

Empowered individuals and teams need information and understanding to work with – such as the business context about why something is important to do in the first place. A manager will not issue orders as much as he or she will answer questions or provide guidance. It is a more collaborative approach where a manager provides a vision, clarity of purpose and direction. A 21st century manager shares his or her expertise and knowledge with the team to help the team improve as well as helping the team to overcome obstacles.