Managed Mayhem

Got me a sweet set!

Now… sometimes you have some tools on your team… but that’s another article.

I must confess that I’m writing this from the perspective of a guy who has invested a lot of time into a specific technology, and is now having a difficult time getting work in that specialization. So take what I’m about to say from that context.

Perhaps a bit idealistic of me here, but why don’t more companies focus on forming great teams with the people that they hire rather than focusing only on hiring for a specific tool? Do you hire the carpenter, or do you hire Ryobi, Craftsman, Stanley, and Makita? Maybe it’s a symptom of the ‘keyword frenzy’ … this long list of acronyms that recruiters and hiring managers are tasked with attaching to the jobs they have open. Maybe they think it is more difficult than it really is for a good developer to transition from one language to another.

I would think it would make sense to hire someone on your team who is a strong Sr. level developer in one technology as a Jr. level developer in another and then train them the way that you want them to be trained. This spirit of ‘Apprenticeship’ is surprisingly lacking in this field, particularly considering the open source movement. I would totally be willing to take a pay cut for 6 months to a year if it meant working on a team with a technology that I haven’t used before, or one that I wanted to gain more confidence in.

I know what you’re going to say… why not hire BOTH for great teams AND the tools you need? And you might be right… but let’s say that it takes an otherwise good developer 3 months to ‘ramp up’ with a specific technology. Now you have a guy who is essentially a Sr. level developer with strong OO abilities working in a Jr. level position for at least another 9 months. They are happy to be working, learning something new, adding to their toolbox… and so long as you are able to promote them as a Sr. within a year, they are probably going to be loyal. You’re going to have a 3 month ramp time regardless. Even if you have a developer who is already proficient in the technology you’ve employed, they are going to need to learn your own unique way of doing things. The kind of developer who would take on a position like that is probably the type who loves what they do, and will work overtime from home in order to get better at it, so you basically get double the hours from them at least in the beginning. The developer’s interest level in the technology is now based on the excitement of learning new things about it. You’re not likely to get that kind of commitment from a guy who has been developing in the same language for a decade.

Really my point is that in technology, tools change… sometimes frequently. Hiring for great teams makes it possible for you to move between tools while still maintaining your culture. If you hire for tools, that is all you get.

I saw this posted on a job board today for a web designer looking for a PHP coder.

“I need someone organized and responsive above all else. I’m talking the type of guy (or girl) who checks email every 20 minutes.”

I thought it was funny… because I’m diligently trying to reduce the number of interruptions to my workflow by only initiating and responding to contact via email, chat, and phone calls during specific periods of the day. You might be ‘responsive’, but you can’t check your email every 20 minutes and be productive. I think this guy is looking for a support tech or project manager.

The problem with working with this type of client in this way is that it never forces them to become more organized themselves. I have burned out on these sorts of babysitter relationships before… and try to be very careful not to take them on anymore.

A non-disclosure agreement (NDA), also known as a confidentiality agreement, confidential disclosure agreement (CDA), proprietary information agreement (PIA), or secrecy agreement, is a legal contract between at least two parties that outlines confidential material, knowledge, or information that the parties wish to share with one another for certain purposes, but wish to restrict access to by third parties. It is a contract through which the parties agree not to disclose information covered by the agreement. An NDA creates a confidential relationship between the parties to protect any type of confidential and proprietary information or trade secrets. As such, an NDA protects non-public business information. -Wikipedia

I’ve probably signed 100 of these things since I’ve been a software developer. For the most part, I don’t have a problem signing them … so long as there is actually an equitable exchange that occurs between myself and the entity requesting that I sign one. 90% of the time, this is not the case. Frequently I’m asked to sign these agreements before anyone has even agreed to hire me for my services, before they will even begin a conversation with me about what they would like me to do for them. At the point when I sign one, I have always felt that I’m giving them something… my freedom to be able to talk creatively with anyone else about whatever this entity values about the conversation that is about to take place, which is usually very subjective… and when I’m being asked on the front end to sign one I really have no idea what the actual value is going to be if anything. I have no way of really measuring my risk of signing an NDA until after the NDA is signed and the conversation is done.

Signing an NDA for a conversation with a startup is even worse because they are usually convinced that all of what they are doing is 100% original. No offense folks, but original ideas are extremely rare… and a startup really does not have ‘trade secrets’ yet. Besides, as a startup … you need all the help and exposure you can get… be smart about sharing within your immediate network, but the benefit from help from folks you do trust far outweighs the legal benefit of protecting your ‘original’ idea from folks that you don’t. Bottom line is… if you don’t trust the person you’re talking to enough not to steal your idea, don’t share it with them at all… NDA or not.

I totally understand why companies would want to protect their interests. I just wonder if the nature of the NDA actually serves to hinder trust and creativity rather than to enhance it.

Unfortunately, the NDA has become one of those tools in the toolbox of managers and executives … and is pretty much a common way of doing business, so they are unavoidable in many circumstances if you want to do business with who-ever is requesting that you sign one.

Here are some things that I always look out for when a request to sign an NDA has been presented to me:

• What is the term?
  Make sure that there is a defined term (6 mos, 1 year) for how long you are being held to the NDA. Seriously consider the value of signing an agreement that holds you to being indefinitely gagged.
• How open / vague is the agreement?
  Is it specific to an industry? Does it specifically name the product that you’re going to discuss?
• What am I really required to keep secret?
  Are there specific things named in the agreement that you are required to hush about?
• Are there exceptions?
  Are you allowed to discuss the contents of your conversation with your partners or contractors?

In my experience, these things are such a pain that combined with the fact that you generally don’t know what you’re really risking until after you’ve signed one … It’s almost not worth it to even go through the effort of having an attorney review them and then have to manage all of the ones that you’ve signed to make sure that you’re in compliance with them. That said, if you think that there is going to be an equitable relationship, and the client is really adamant about having an NDA, I would recommend having an attorney look at the agreement.

When I go to the mechanic to have something fixed, he charges me an ‘evaluation fee’. When I need an attorney, I will usually get a first visit free, but anything after that is billable no matter what it is. If I go to the dentist or doctor, I pay for a visit (sometimes several!) before I am told what is wrong.

Why is there the expectation in custom software design and development that we should give free quotes / estimates?

I think that this expectation is the primary reason why we have such a rash of ball park estimates in this industry. If it’s only a ‘contest’ of who can come up with the best price and not the best plan… why bother coming up with a plan at all?

For projects over a certain dollar value, I will build a requirements specification / definition that includes (among other things):

• Functional Specification
• Design Specification
• Technical Specification
• Module / Component break-down
• Server Architecture (If required)
• Delivery Milestones / Schedule
• Budget

When I build a requirements definition that leads into a proposal, there is sometimes research involved for the specific technology or need that the client has, primarily because they are looking for specific solutions and someone to solve problems for them.

I once had this client who wanted to setup fax on demand via the web and via an 800#. I had never worked with fax on demand, but I spent the time and researched it, found a vendor for them, talked with the vendor about the project and the customizations we’d need for their software, negotiated with the vendor on price and added that to the project budget along with information about the vendor and their technology in the technical specification.

Many clients I have worked with had a very basic idea that after several brainstorming sessions turned into something much more lucrative and easier to accomplish than what they had originally set out to do.

Yet another prospect of mine wanted to have the ability to make (not just take) online payments via ACH. I’ve never done this before… but after about an hour of research and some phone tag, I got it figured out.

Many times I can’t meet 100% of the client’s needs myself or even with my immediate team, and so I need to step outside of that and find someone who can help. Sometimes I don’t even know if what the client is wanting to do is possible!

My point is that all of this consulting effort prior to proposal to ‘get it right’ takes time, and there is value during this process when it is done properly.

Early on in my business, I found myself building out proposals and coming up with sometimes great ideas that prospects would then take and use with someone else who outbid me. During the interview process and initial relationship forming, it is inevitable that there is an exchange of knowledge / value from our side to the client’s side. This business of business, systems and software analysis is primarily a consulting role that we take on particularly early in a project… and knowledge that we’ve developed over the course of our careers is frequently freely given away while we go through the bidding process.

I’ve gotten to the point where I’ve realized that rather than needing to feel protective about these things, to make sure that I can give accurate estimates, and to avoid the tendency to just lazily ‘ball-park’ projects, I decided that I would build proposals over a certain dollar value out of actual requirements by spending the time interviewing the client for as long as it takes, researching about their needs, and expecting that I get paid for properly building out a schedule and budget for them. That consulting process is now a part of my product / service, and I give them an up-front estimate of how long I think it will take / cost based on the initial information that I get from them. Reviewing client material and interviewing them over a period of time prior to forming an estimate or proposal helps to develop a realistic schedule and budget and develops a true relationship of trust with clients who are serious about working with me because they respect what I do, and are not just looking for free consulting and a bid for work that may never come. It allows us both to take each other seriously and develop a solid and realistic plan together.

I will openly admit that this ‘rule’ has resulted in lost ‘opportunities’ because many others do not follow it, and so many prospect’s expectations are improperly set by other developers or firms. I’m ok with that. My intention is not to have a large number of opportunities, but rather… a small number of strong relationships that I’m purposed to be involved in. It is in this sense, my ‘Purple Cow’ method.

After going through this process with a client, I’ve never had them take the result and go somewhere else with it because I’ve been able to take the time to prove to them that I’m an asset to their team. If they do ever decide to go elsewhere because of price, they have a well defined requirements specification / scope that they can take with them, and I got paid for my time. I would have rather gotten the gig, but both of us are (relatively) happy. When I haven’t gone through this process with a client, 90% of the time, they go elsewhere for a lower bid because they were only after price, and my pessimism skews my ball-park estimates high. Or if I do go through the process with them, they don’t buy,  and I don’t get paid for it, 100% of the risk is on me and I feel like I’ve been ripped off. That is a waste of everyone’s time. I don’t compete based only on price, I compete based on quality, honesty, and experience. Some of these folks have come back to me after going out on their own without going through this process in order to start over.

The company I just left went through that same thing where they did not want to hire me on the front end to help them through the dream and define process… and as a result, they spent $50,000 and lost a year of effort, and still came back to hire me and one other guy (who i interviewed) in order to rebuild their application from the ground up because it was insecure, not highly available, not ready for production, and ugly. They had a huge opportunity cost because they effectively lost almost 2 years where the product wasn’t taken to market due to a failure to plan or set expectations properly on the front end with the developer they were working with. That’s not the first time I’ve been pulled in after the damage has been done.

Now, I’m not talking about your average contact form, CMS installation, wordpress theme / customization… or ecommerce website using existing technology. I’m not talking about web site design. Systematic, Cookie cutter, packaged, or single feature type requests don’t even need to be estimated. I have a default price list for almost anything you can think of when it comes to these ‘one off’ type requests, and even website design is standardized enough that you can easily quote it based on the number of layout revisions and pages being laid out. I’m not even talking about feature requests made during maintenance of existing applications… though that can be another beast in itself.

It’s the larger, new custom projects that I’m really addressing. Think about it like this… traditionally, planning for any project should be about 10-20% of your project time. If you have a 1000 man hour project, that is 100 to 200 man hours worth in planning. This planning is going to need to be done at some point no matter what. Why not at least do some of it BEFORE you have already developed a budget and schedule so that you can be more confident in what your budget and schedule will be? It just seems backwards to me to trust a developer (or firm) who is motivated primarily by making the sale and getting a proposal done quickly … to spend the time necessary to form a solid plan required to give you an accurate budget and schedule without paying them to do it. Pay them to do it right, and make sure that they clearly understand your needs before you accept a budget or schedule from them. If you’re unhappy with the price afterwards, at least you (hopefully) have a well documented functional specification that you can take to another developer and you can get an accurate quote from them using it.

I frequently run into the request for a ‘ball-park’ estimate for software development projects. I loathe to give these type of estimates. They are inherently dishonest from the very start because they are a ‘promise’ based on incomplete and sometimes incorrect information.

I love to give a free one hour consultation for my clients. It gives us a chance to get to know each other, introduces me to their product or idea … and begins the process of figuring out ways that I am able to help them. I can usually tell rather quickly within this one hour period if I’m going to be an asset to their team or not. In most cases, clients have a very basic idea of what they are really wanting to accomplish. A loose set of ideas, sometimes scribbled on a notepad or napkin while you watch. Other times, clients will actually have some prior education and will have something a little more organized… perhaps some storyboards or a diagram showing what they want to do. This is better, but honestly… still not enough to give a proper estimate.

The problem that I have with ball-park estimates is that they are too subjective and emotional. I might be hungry that day, or I might not be hungry at all. I might be really excited about working with this particular project or client, or perhaps I’m not really interested in what they are doing but still want to help. Maybe I just want the client to like me. Maybe I’m without work at the moment, or I might be swamped. None of these things should really matter when building project estimates because they are subjective, emotional, and variable. We have all been in that position where we were without work, underbid a project (usually as a ball-park estimate) and then half-way through the gig we’re late, overbudget, swamped with new work feeling taken advantage of, and no longer really motivated to do a good job. Why do we do this?

When I have given them, my ball-park estimates for custom software development swing manic depressively between polly-anna optimism and grinch like pessimism. This is never good because either way, someone is going to be unhappy with the end result. If I am pessimistic and shoot high, clients get skittish or I automatically lose to moderates and optimists without the opportunity to close. If I am optimistic and shoot low, inevitably the client is disappointed anyhow because:

• Time lines are missed
• Market opportunities are missed
• Budgets are missed
• Rush to release results in mistakes

Some clients have been thinking about and developing their product / idea for years… it’s only reasonable to expect that we are given the time needed to study their product / idea thouroughly in order to do our jobs properly. There are a lot of software development firms out there who  with respect to setting budgets…they hedge on margin / volume, or occasionally getting lucky. They figure ’some we win, some we lose’.

I don’t like to lose… I like both the client and me to win every time.

The analysis portion of our jobs as software developers is primarily about reducing risk. I see gambling with incomplete / inaccurate project estimates as a risk that is deadly to projects, and one of the primary reasons why they fail. Get as much information about the project up-front. Spend the time that it takes to get as accurate an estimate as possible. Don’t worry about being perfect, but at least make the attempt.

I promise to write an article about how I estimate software projects soon. For now, feel free to comment about some of the project estimation tools you’ve used that have worked for you!

Waterfall Model
The Waterfall software development methodology is one of the most widely known and recognized methodologies. Originally designed for the manufacturing and construction industries, it is called ‘Waterfall’ because of the way that it’s phases flow downward, similar to an actual waterfall. It is best uesd for projects where the requirements are clearly stated and static, or where it helps to have a rigid management structure with up-front requirements and agreed timeline and budget. Many times the decision to use Waterfall over another method (such as Agile) is simply a matter of the personalities involved in the project, including the project sponsor. Using the Waterfall software development life cycle, the implementation of the system is preceded by requirements definition, analysis, design and development. One problem with the traditional waterfall method, is that it is impossible to perfect one phase alone before moving to the next phase. Another issue with waterfall in general is that the nature of design in any creative field (software development included) makes it difficult if not impossible to define all of the requirements up-front or even prior to completion. In a project where requirements are always changing, and new ideas are being formed as design proceeds creates a ‘moving target’ syndrome where the waterfall model just does not fit.

Sashimi Model
The sashimi model (so called because it features overlapping phases, like the overlapping fish of Japanese sashimi) was originated by Peter DeGrace. It is sometimes referred to as the “waterfall model with overlapping phases” or “the waterfall model with feedback”. Since phases in the sashimi model overlap, information of problem spots can be acted upon during phases that would typically, in the pure waterfall model, precede others. For example, since the design and implementation phases will overlap in the sashimi model, implementation problems may be discovered during the design and implementation phase of the development process.This iterative method helps alleviate many of the problems associated with the traditional philosophy of the waterfall model, but does not fully address the organic nature of some software projects. Theoretically, one thing that it is good at is managing your costs during the project by keeping your iteration between two phases at a time. Ideally you will not iterate backwards beyond the previous phase, as if you are already developing and find that you are iterating back to requirements… there was a (potentially expensive) mistake made during the ‘Design and Architecture’ phase. Because this modified format of the traditional waterfall method is one of the most common (It is the one I use when using waterfall), this is the one I will be focusing on within this article.

Requirements
One of the most important tasks in the development of software using the waterfall method is gathering and defining  the requirements for the project.  Software requirements analysis is a rather broad field of software engineering and project management, but simply put … at the end of a requirements phase within the waterfall method, all involved parties should have a basic understanding of what is going to be developed, and at this point the requirements are written as ‘prose’, and are not usually very technical in nature. In some cases (particularly with smaller projects), a budget and timeline estimate is also formed, though in my opinion this is best done after the Design and Architecture phase, when the majority of the costs are more accurately known. For this reason, I will normally split my billing into two major phases … the first includes the first two project phases, ‘Requirements’ and ‘Design and Architecture’, usually billed on retainer. The second major phase includes the remaining 3 waterfall phases, split into three major billing phases of ‘Development’, ‘Testing’, and ‘Implementation’.

Design and Architecture
When discussing this phase of the waterfall method with my clients, I compare it to the design and architecture of a construction project. Before you build a custom building, you need to go to an architect in order to have that building designed. When building software, it is very similar. Software developers who specialize in this are even called ‘Software Architects’. During the Design and Architecture phase of a project, a Software Architect is responsible for defining with the project sponsor the functional and / or technical definition of the project. At times, tools such as wireframes and/or storyboards are used in order to help the architect to communicate with the developers and the project sponsor. Other times, UML (Unified Modeling Language) is used… though this is generally only used to communicate with other developers, as most project sponsors are not going to understand it. I have even developed the user interface of a software project during this phase in order to help the communication process between our team and the project sponsor. Keep in mind that the Sashimi Model that we’re using is iterative, so we’re constantly going back and forth between this phase and the last. Until the prior phase is fulfilled by this one.

The tangible result of the Design and Architecture phase should be a solid plan that defines the platform that is going to be used, the flow of the application, a hardware specification showing what hardware will be used… etc… Other tangibles may include the aforementioned wireframes, storyboards, and sometimes even a prototype user interface design.

Development and Coding
Once we all know what we’re actually doing, now the fun part begins! Part of the reason why the initial two phases of the waterfall process are so important is that this phase is the most time consuming and most expensive. Getting something wrong at this phase will inevitably mean one of two things… rework, or an unhappy client. Even when rework is done, this creates a situation where the client’s project might be late, or if not hers… someone else’s! Again, since we are using Sashimi Waterfall, the ‘Development and Coding’ phase overlaps with the ‘Design and Architecture’ phase until this phase fulfills the requirements of the one prior to it.

Quality Assurance and Software Testing
One of the most obvious improvements to the waterfall model when using Sashimi is during the testing phase. Because of the iterative approach of Sashimi, testing occurs as part of the development process, and then again as part of the deployment process. Develop, Test, Develop, Test, Develop… until the testing phase fulfills the development phase, Test, Implement, Test, Implement… until the application is fully tested and successfully deployed. Testing will also sometimes include several of it’s own minor phases… sometimes called ‘Alpha’ or ‘Beta’, other times managed as versions of the project with a version 1.0 project being a final first release. There are also several different types of testing:

Unit Testing
Integration Testing
System Testing
Regression Testing
Functional Testing
Performance Testing
Load Testing
Compatibility Testing

All of these are outside of the scope of this article, but I might be convinced to write another one down the road about testing.

Implementation
This is the phase of the project where the developed software is installed (or deployment scripts are delivered), documentation is written or cleaned up (as documentation should be written as an ongoing part of the development process), and sometimes client training will occur. Implementation is the only phase that I will sometimes overlap backwards two phases (between Deployment and Development) since there are sometimes things that are caught between Implmentation and Testing phases that require additional development to resolve.

Maintenance and Support
After the project is released into the wild, bad things can happen. This is why it is important that continued maintenance and support is addressed within any software development process. With the needs of clients and technology itself changing constantly, this support becomes an evolving process… and is essential to making sure that the software continues to perform as expected. I will normally move this phase out of the waterfall, and treat it as a separate project entirely as the nature of supporting an existing project can be very different from building a new project.

————————————————————————————–

As a side note, within my own waterfall process (when I use it), I have modified the waterfall model into an easier to remember system called the 5d’s:

Dream (pre-Requirements)
Define (Requirements)
Design (Design & Architecture)
Develop (Development and Coding)
Deploy (Includes Testing and Implementation)

Again, I will usually separate the maintenance of the project from the project itself, preferring a separate process for handling ongoing support.

Hopefully this article was helpful to those who are learning about the management of software projects. I think that all of the available models have something that you are able to take away from them. I’m not really a purist with any of them, and try to fit bits from all of them when they make sense for the particular project I’m involved in. Despite some of it’s faults, waterfall has it’s place… and I think that the addition of overlapping phases within the Sashimi model improves it dramatically. I probably would not use it without this modification.

I’ve been developing web software for over a decade now. As a result, I’ve had the opportunity to use quite a few project management platforms. I’ve even homegrown a couple along the way. The last several months, now that I am back to freelancing again, I have started using openGoo. The openGoo application is based on ActiveCollab’s last open source version, and it is a significant improvement both in functionality and form. It uses the EXT javascript library, which is a fantastic javascript UI, though it is a bit slower than others. Current stable release as of this writing is 1.3.1, and I’ve used it every day for the last month and a half with only very minor issues… which are expected in any open source project of this size. All of your projects are organized into ‘Workspaces’, with the ability to organize sub-workspaces as well. Security is fairly granular, allowing for user / group permissions at the workspace level. OpenGoo has the following modules included:

Notes
I use this primarily to keep track of workspace specific notes like login information, IP addresses… stuff like that.

Email
I have not used this yet because it is still in beta, but it enables you to check your email from within openGoo as a client. I can’t wait until they get all the kinks worked out!

Contacts
Pretty handy for keeping track of the folks who are involved in projects, though it would be nice if it integrated with existing CRM or contact systems. I use SugarCRM quite a bit, and so having to double enter contact information is a pain. You can import contacts and companies from a .csv file.

Calendar
openGoo comes with a very good calendar that integrates across all of the projects that you’re involved in so that you can see at a month / week / day view what you have going on. Really snazzy.

Documents
I use this in order to keep track of files and documents specific to the workspace / projects I’m working on. If a designer sends me a .psd file to slice up, I’ll put the original .psd file here. Any requirements documents will also go here. Content related to websites, customer agreements, etc…

Tasks
Probably the most used module within openGoo, you are able to assign tasks to any user, attach time to tasks, start date, due date, priority, milestones, and even tags. The task dashboard allows you to see what is current / past due at a glance, for all workspaces, all tasks, all users. There are also several sort options.

Weblinks
I don’t use this very often, but it is basically just a repository for links related to the workspace / project.

Time
Time reporting within openGoo needs some work. It is actually a bit buggy, but the way that time is assigned to tasks is actually very smart. I am looking forward to what they do to resolve the issues with the reporting functionality. For now, I export all of our time out of mySql using a small php report I wrote.

One of the things that I really enjoy about openGoo is that they have a very fast development cycle. I started messing with it at version 1.0 about 3 months ago, and they are already on 1.4.0 rc2. I’m amazed with how quickly they have been moving through releases. The community is a little weak / inexperienced, but the staff who are working on the project are very good about answering questions in the forums. This is huge for an open source project that is used for commercial purposes, especially for something as important as project management.

I’d like to see how they handle the billing capability within it though… right now I’m not so happy with the fact that it does not allow you to set per workspace billing rates or per service rates either. All billing rates are based on the user performing the work. This also does not take into account your actual cost as a development firm. The way that they handle accounting within openGoo is not the greatest, but I think that they will improve upon it.

All in all, openGoo is one of the best collaborative platforms I’ve used in a long time.