SSW Rules to Successful Projects

What is it that makes a good software development consultancy? What sets one company completely above the other? What makes a project completely successful?

There's no doubt custom software development is a challenging industry. According to the Standish Group Report, 1999: Nearly 75% of all development projects missed their target release date or never ship at all. But what I find so interesting is that at least 7 of the 10 most common signs of product development failure are present before the design is created or a single line of code is written. (John S. Reel 1999).

The promise of a successful project is something we all work harder to achieve, but working harder is not the answer. Software companies need to work smarter before, during, and after development, to ensure that the client gets not only what they want, but what they need.

There are real gurus in this field like Joel Spolsky , Kent Beck , Tom DeMarco and Timothy Lister . We like what they say, but we also reckon they miss a few things as well - everyone has their own ideas. These are the rules we run by every day. We believe they can help every software developer and team manager to deliver better code and a better end product.

Do you agree with them all? Are we missing some? Email us your tips, thoughts or arguments. Let us know what you think.

1. Do you understand the value of consistency?

   If you need to do something more than once, then there should be a standard for it. At the heart of our philosophy on creating rules and standards is the idea of consistency.

   Say we are creating a windows forms application. We can expect to:

   • Improve productivity - because there are less decisions to make, and you build on existing work.
     For example, we don't need to discuss the pros and cons of MDI versus SDI because there is already a standard.
     
     
   • Improve quality - because you are following best practices.
     For example, which logging library is better out of Microsoft Application Block or Log4NET.
     
     
   • Improve communications - because people know what to expect.
     For example, when we complete a task we are clear and educate the customer by including a screenshot, the code and the time taken. We are consistent on whether we call it a bug or a feature because we define what's a bug.
     
     
   • Get straight to the meat of the customer's problem.
     For example, our developers don't need to decide whether to implement baseforms or user controls. They already know because it's covered in Rules to Better Windows Forms Applications.

   At SSW we create standards for all manner of processes: from coding practices to project proposals and how to lock the office up at night. From the developer's perspective, consistency means that we understand each other's code, and if we don't know something, a standard will often save us asking someone. No more Chinese whispers, and less time wasted. From the customer's perspective, consistency leads to a reliable and repeatable experience.

   The following story illustrates these values:

   The Barber (excerpt from "The E Myth" page 105)

   I went to a barber who, in our first meeting, gave me one of the best haircuts I had ever had. He was a master with the scissors and used them exclusively, never resorting to electric shears as so many others do. Before cutting my hair, he insisted on washing it, explaining that the washing made cutting easier. During the haircut, one of his assistants kept my cup of coffee fresh. In all, the experience was delightful, so I made an appointment to return.

   When I returned, however, everything had changed. Instead of using the scissors exclusively, he used the shears about 50 percent of the time. He not only didn't wash my hair but never even mentioned it. The assistant did bring me a cup of coffee, but only once, never to return. Nonetheless, the haircut was again excellent.

   Several weeks later, I returned for a third appointment. This time, the barber did wash my hair, but after cutting it, preliminary to a final trim. This time he again used the scissors exclusively, but, unlike the first two times, no coffee was served, although he did ask if I would like a glass of wine. At first I thought it might be the assistant's day off, but she soon appeared, busily working with the inventory near the front of the shop.

   As I left, something in me decided not to go back. It certainly wasn't the haircut-he did an excellent job. It wasn't the barber. He was pleasant, affable, seemed to know his business. It was something more essential than that.

   There was absolutely no consistency to the experience.

   The expectations created at the first meeting were violated at each subsequent visit. I wasn't sure what to expect. And something in me wanted to be sure. I wanted an experience I could repeat by making the choice to return.

   The unpredictability said nothing about the barber, other than that he was constantly - and arbitrarily - changing my experience for me. He was in control of my experience, not I. And he demonstrated little sensitivity to the impact of his behaviour on me. He was running the business for him, not for me. And by doing so, he was depriving me of the experience of making a decision to patronize his business for my own reasons, whatever they might have been.

   It didn't matter what I wanted.

   It didn't matter that I enjoyed the sound of scissors and somehow equated them with a professional haircut.

   It didn't matter that I enjoyed being waited on by his assistant.

   It didn't matter that I enjoyed the experience of having my hair washed before he set to work and that I actually believed it would improve the quality of the haircut.

   I would have been embarrassed to ask for these things, let alone to give my reasons for wanting them. They were all so totally emotional, so illogical. How could I have explained them, or justified them, without appearing to be a boob?

   What the barber did was to give me a delightful experience and then take it away.

   What you do in your model is not nearly as important as doing what you do the same way, each and every time.

   Figure: The Barber, Excerpt from "The E Myth" p 10

   Standards don't need to come at the expense of creativity. Following standards means less time doing the administrative stuff and more time for the creative. Of course standards are works in progress, and so we are always on the look out for improvements. That's why standards should be shared with everyone.

   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/DoYouUnderstandTheValueOfConsistency.aspx

2. Do you know that Rules are made for the guidance of wise men and the obedience of fools?

   This means that standards shouldn't be followed blindly and may need improving.
   Note: With respect to these rules, if you think something can be done better, than we have documented here, please let us know.

   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/Rules.aspx

3. Do you manage clients expectations?

   Software development can be painful and costly. Hang on, that should say "Software development IS painful and costly." Well, not always, but it has been observed that in 1999 "75% of all development projects missed their target release date or never ship at all." Projects often fail because clients think suppliers under-deliver and over-charge. The client and the supplier have different expectations about the goals of the project. This difference of opinion often leads to a projects absolute failure.

   Don't give ranges! Let's say a prospect asks me "how much to do this Release?" I could say - "somewhere between $15k - $20k". I hear 20, the prospect hears 15. I'm pleased we got it done for $25k with a whole bunch of changes, the client is annoyed we didn't get it done in 12. So I never give a range to a client. I tell them that the first Release, along with its spec is likely to take $20k. That's two guys working full time for two weeks.

   Be upfront about bugs I don't believe there is such a thing as bugless software. It's important to admit that bugs will happen. Bugs will get through testing, and bugs will cause a headache in production. In a fixed price agreement we cover bugs, because the goal posts are stuck in the ground, but in hourly-rate work, bugs are covered by the client. See what is covered in fixed price contracts for more information in relation to what is and what is not a bug.

   Fixed prices don't solve anything: A big fixed-price contract can also be dangerous in managing expectations because it removes flexibility. If you deliver exactly what the spec says, the client can quite easily be unhappy, because the hundred and one things they thought of during development weren't included. I recommend fixed-prices in Releases of no more than 3 weeks development which helps alleviate this problem. It will often occur that in the middle of a fixed price contract a client will ask you to add extra functionality. You should not do any such items straight away, but turn this request into a task for future development. At SSW we convert the task into an email, then use SSW eXtreme Emails! to generate a release plan for all the extra items once the fixed price contract has been signed off. It is important that the customer is always clear on what is part of a fixed price contract and what is not, that is why you should always finish a fixed price contract and have it signed off before starting extra work.

   Talk dollars at the first meeting: Talking dollars with the client is often something consultants don't like doing after the initial meeting. I've heard of consultants refraining from sending invoices when a project is suffering a few delays, or the client is unhappy with the application state. What makes this consultant think that if the client is unhappy to receive an invoice now, they'll be happy to receive it in two months? We send invoices for time and material projects every week, this way the client is informed of costs every week, and if a hassle arises, it's trapped straight away.

   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ManageExpectations.aspx

4. Do you pursue short or long-term relationships with clients?

   I have been told that it's good to treat clients the same way you would treat a prospective partner - that is, with lots of TLC.

   The first kind of approach is where you try and seal the whole deal in one go: "I think we would work well together, would you like to get married and have two children?"

   The usual response is "Get lost you loser."

   The second and more appropriate approach is asking something like "Would you like to have coffee together?". You have a greater chance the prospective partner will say "yes"...

   Unless you are a great salesperson, who has constant exposure to new clients, then I suggest you use the 2nd approach. Clients are likely to be frightened off with huge quotations, so by segmenting the project into smaller projects it waives some uncertainties.

   For example:

   The initial meeting concludes with us telling the clients that we will prepare a proposal (for free), which will have a series of release plans costing $100K.

   Figure: Any new prospect should not be handled in this way, as it is too big of a figure for a first taste of your work

   To conclude the initial meeting, we tell the clients there are two options to consider. The next step is the Specification Review, which will take 2 days with 3 developers.

   Figure: Clients are more likely to appreciate this approach, as they are given the option of proceeding with a small project with prospects of continuing to work with you based on how well the previous project went

   
   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ShortLongRelationships.aspx

5. Management - Is your client clear on how you manage projects?

   Software must help a business become more efficient and build better relationships with their clients. This means that software must also be cost-effective and quick to market. Traditionally, software has been slow to build and difficult to change.

   SSW's Rules to Better Project Management, built on eXtreme Programming, allows businesses to address their most important challenges first, and respond quickly to a changing commercial environment. We prefer to work on-site, in close consultation with you and your business users, becoming an integrated part of your team. We believe these rules deliver functional, value-adding software - faster.

   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ManageProjects.aspx

6. Management - Do you enforce deadlines, have a project release plan, a debrief, a mark /10 and a status meeting?

   Developers love doing things in their own time, investigating interesting things they find on the web and generally they're easily distracted. If they don't have a project plan constantly in front of them they'll never deliver on time!
   For every project you must have 3 essential things:

   1. Every 2 weeks the developer has a meeting with the client to discuss the status of project.
      If you can't have a meeting, a phone call is fine.
   2. A status update if the release is not yet complete
   3. If the release is finished then it will be a release debrief.

   Often when things are going right, the tendency is to let things be. A better idea is to figure out why things are going right, and work out how you can repeat it.
   For example, if your client calls and says, "We think Dan has shown very professional conduct and has delivered a high-quality solution", you should look at how the project was run.
   Was the solution high-quality because your developer followed your coding standards? Was his professional conduct due to lots of customer interaction and polite and clear communication?

   Of course, if in your release debriefing you find that the client is unhappy due to bad conduct, scope creep, or poor quality code, you need to check that your standards are being followed to ensure a positive experience in the next debriefing.

   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/EnforceDeadlinesHaveAProjectReleasePlanADebriefAMark10AndAStatusMeeting.aspx

7. Management - Do you only work from an approved release plan?

   Unless you are working under an ad-hoc basis you should always be working from a signed release plan.

   At the start of each release put together a release plan which is then sent to the client for approval. Arrange an appointment (subject "Debrief: Project Name") for your project manager to come in and do a review in 2 weeks. This doesn't set unrealistic schedules, but puts pressure on the developer to have something done by then.

   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ApprovedReleasePlan.aspx

8. Management - Do you have a Release Debrief?

   At the conclusion of the internal and external "test please", but before deployment, you should meet with the client to discuss the release. The purpose of the meeting is to:

   • Compare what we were ask to do
   • vs What we did
   • Compare estimates estimated costs for that release
   • vs actual
   • Review any additional items
   • vs items moved to the following release
   • Monitor any known metrics of the project
   • Eg. Lines of code
   • Eg. Lines of markup e.g HTML, XAML
   • What went well
   • vs what didn't go well
   • Ask for a mark out of 10 for how well the release went
   • Any other issues to do with time, scope, cost or quality
   • Decide to proceed to deployment
   • Next Releases

   Other Tips:

   • The confirmation email subject should be "Northwind - ProjectName - Release02 Debrief"
   • You can send a release debrief email with eXtreme Emails
   • A release debrief should be held even if an external "test please" hasn't been passed.
   • A release debrief should be scheduled for no later than 1 week after the initial estimated completion date.
   
   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ReleaseDebrief.aspx

9. Management - Is your client clear on the definition of a bug?

   The answer to this question can make or break contracts. We think that it's such a fundamental issue it has to be captured clearly. This is how we strictly define it:

   "A reproducible coding error that causes an unexpected defect, fault, flaw, or imperfection in a computer program." In other words, if any of the developed software does not perform as the developers intended, it is most likely a bug.

   You can tell it is a bug when:

   1. It is able to be reproduced
   2. The application crashes to code (runtime errors should be handled or avoided). This does not include bugs in third party products (e.g. Blue screen of death, or crashing in a third party data grid that we cannot control)
   3. The application displays incorrect values
   4. The application is missing specified functionality that was agreed in the Mock-ups or specification
      
   Examples of what is a Bug:

   Examples of what IS included in a fixed price contract (i.e. bugs). These are primarily technical (rather than business logic) errors made by the developer. Technical workarounds because of unforeseen limitations of technology are covered by a fixed price contract.

   1. A sum total is negative instead of positive because the developer used the wrong operator (plus instead of minus) to calculate the running balance. (This is a bug because it crashes to code)
   2. The application crashes because it doesn't check that a connection is valid before running a stored procedure. (This is a bug because it crashes to code)
   3. The output HTML in the application is not correctly formatted, and does not display in the specified browser (e.g. Internet Explorer 5). (This is a bug because it displays incorrect values and crashes to code)
   4. The fixed price contract says that the converted VB.NET Windows Forms application has "comparable" or the same functionality as Access. The original application uses Docmd.SendObject (i.e. uses Outlook), which has the brokers "from" address. The converted application uses reporting services (as recommended by the developer). However, this always has the same "from" address - and functionality has been lost. The modifications to use a web service for the "from" address are covered by the fixed contract. (This is a bug because it is missing specified functionality)
   5. Defaults are in the UI mock-ups, but they are not in the final application (this is a bug because it displays incorrect values)
      
   Examples of what is NOT a Bug:
   1. Any problem caused by software or an application not written by SSW.
   2. The customer requirement was not included in the user interfacemock-ups/specifications.
   3. The client decides that they don't like the look of the current form even though it is the same as shown in the specification and wants the buttons at the bottom of the form instead of at the top.
   4. The original specification states that the total price excludes GST, but it really should have included GST. This is a change to the specification, and is not included in the contract.

   More specifically, when using SSW eXtreme Emails! during a fixed price contract, any new features or modifications (non-bug items) not in the original Pre-Release plan are additional work and are outside the scope of the contract. Any Incidents which are bugs should be marked as additional items and be completed in the current release if possible. Most importantly, after the Pre-Release plan has been sent, an Incident should NOT be entered as an item (additional or otherwise) in ANY releases if they are not a bug. Instead, move all non-bug items to the zsUnallocated folder for future review after the warranty period for the fixed price contract has passed.

   If you see a bug in an SSW software product, please report the issue following the steps outlined the SSW Bug or Enhancement Reporting Standard.

   Note: The above is our definition. Others have different definitions that we do not subscribe to: http://www.joelonsoftware.com/articles/fog0000000029.html

   What is the warranty period?

   The warranty period is a period of time when reported bugs will be covered by the fixed price contract. The warranty period is 30 days if not extended. If a bug is found during the 30 days, the warranty period is extended to 30 days from the date the bug was reported. For example, the developer introduces a new bug on the final day of warranty as part of a bug fix, but this repair work/fix introduces a new issue or bug - reported on the next day. In this case, the newly introduced bug will be covered by the fixed price contract.

   When using SSW eXtreme Emails!, the warranty period would begin when you send the "Test Please" email, directing the client to the current version of the application.

   *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/BugDefinition.aspx

10. Management - Do you maintain verbal contact with your client?

    With the convenience and cost-effectiveness of email, it is tempting to resort to emails for client contact. We sometimes forget that our clients are people just like us who need human interaction to ensure everything is OK. This is why it is essential that you maintain verbal contact before, during and after a project. What does this mean?
    1. Let the client know what to expect in terms of communication, i.e. :
       1. "The first step is, we send you a release plan to approve. Once approved we can begin work"
       2. "Every morning expect a 'Morning Goals' email with a list of tasks the developers will be working on that day"
       3. "Every time a task is done, you will get an email with information about the task such as time taken, screen shots and code snippets"
       4. "If you need to change the priority of a task, just let us know and we will consider it for inclusion either in this or the next release depending on its importance"
    2. Avoid going more than 3 days without a phone call
    3. If you are put onto an existing project, it is good practice to call the client and introduce yourself. For example, "Hi, I'm Andrew. I'll be taking over from Mark on your project. Mark has filled me in on the specifics and I'm keen to get involved."

    If you maintain an open channel of verbal communication with your client, it helps to break down communication barriers, lets the client know that you are friendly and involved, and makes them feel comfortable with you and SSW.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/Verbalcontact.aspx

11. Management - Do you know who has authority?

    Figure: Sample Change Request Confirmation email

    To: Angelo; Cc: John, Sophie Subject: Changes Requested by Sophie As per our conversation, Sophie has requested the following changes to your application: modifying rptContractRenewal to include the "MaidenName" field from the ClientContact Table, and positioning right next to the Surname field. Please let us know ASAP if you don't want this problem fixed. Thanks, John www.ssw.com.au

    Ok, once a project gets going, you can end up dealing with many people on the client side. From the Boss to the Business Decision Maker (we call them the "Company Champion") through to Mary the receptionist (aka "users"), everyone has something to say about the software as it is being developed. However, when you are working on a Time & Materials basis in a rapid development environment with continually changing specs, you have to be certain that the work you are doing is authorized by the person who signs the cheques.

    So, say Alan from Accounts would like the Username and Password authentication to have a "remember me" checkbox for the Accounts module. This sounds reasonable, but it doesn't mean that you should charge right in and start coding.

    As an example, this is how we govern this process:

    • At the beginning of the project one of the client staff is assigned as Company Champion. This person has full authority from the Business Decision Maker of the client as to what work is IN or OUT. Every new item of work must be authorized by this Company Champion.
      
      
    • Whenever someone who ISN'T the Company Champion makes a request for work, the Company Champion must be CC'd. If Mary the receptionist has not done this, the developer sends the email again to himself, and CC's the Company Champion (CC'ing other relevant people - if they may give feedback on the task) to let them know about the request.
      
      
    • We make the assumption that the task is good to go, so it is the Company Champion's job to make sure that they reply ASAP if they don't want the problem fixed.
    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/WhoHasAuthority.aspx

12. Management - Do you spec in bite-sized pieces?

    The first problem with specs is that nobody writes them. Joel Spolsky says "Writing specs is like flossing: everyone agrees that it's a good thing, but nobody does it". We know developers like writing code more than specs, but the rule is developers don't code without a spec (including a release plan).

    The second problem is that when people do write them, they try and spec the whole project, spending months detailing every Use Case, Business Rule and Process Flow Diagram. The client spends lots of money and sees no real progress, and the requirements change and the process begins again.

    For example, if your client wants an application that manages Customers and Customer Projects, get the whole Customer phase up and running before you get Customer Projects running. This way you have two 1 month deadlines, instead of 1 two month deadline.

    At SSW we spec in two phases, the first to get an overview of the project, the second, to focus on the detail of first few releases only:

    • Spec Review, or Initial Release Plan
    • Detailed Release Plan - this phase is repeated through the project
    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/SpecinBiteSizePieces.aspx

13. Do you conduct specification analysis by creating mock-ups?

    Complex documentation can waste time. Many user requirements can be best encapsulated in screen mock-ups.

    Spend more time on mockups over time on word documents, because they identify basic functionality and minimizing refactoring.

    And more amazingly they identify small but important requirements that often lead to more requirements. Eg. a message to a user, where the customer wants the URL to be clickable (meaning the standard MessageBox will not be appropriate..

    Here are some hot tips on mock-ups:

    • Avoid the thought of a "throw away" prototype. An example of a throw away prototype is when you design screens in Access, but the application will be HTML. So design the screens you and the customer are happy with the technology you will be using, and then use them in the app.
    • It is best to have a designer and developer and customer working together.
    • Get the mock-ups physically initialed, especially if you are performing a fixed-price contract. Yes paperless is great - but not in this case.
    • Mockups should cost the customer money
    • A tip I picked up from Tom Howe was always add a client's branding into the mockup - it makes a big impression
    • Mock-ups should follow standard interface rules
    • Write the related business rules at the bottom of each screen - and turn into unit tests.

    There are five primary types of mock-ups:

    • Hand drawn Mockup;
    • Wireframe Mockup;
    • Developer HTML Mockup;
    • Designer HTML Mockup;
    • Designer Photoshop Mockup. (recommended)

    More details on the different types of mockups/prototypes:

    • A 'Hand drawn Mockup' - A sketch:
      Copy from A 'Hard drawn Mockup' example

      

      Figure: Hand drawn mockup example - recommended to do with customer, however doesn't deal with any styling/color issues, so Photoshop Mockups is still needed.

    • A 'Wireframe Mockup' - A layout of how controls would look in static form, no interaction in image format. e.g Visio or hand-drawn:
      An example of Wireframe Mockup

      

      Figure: Wireframe mockup example - not recommended as it completely thrown out.

    • A 'Developer HTML Mockup' - These are mockups in a Web/Windows Forms/Access UI with limited functionality:
      An example of an ugly Develop HTML Mockup

      

      Figure: Developer HTML Mockup example - not recommended as it is a bad starting point from a HTML view and refactoring later is harder (if even possible) + this reeks of Bodgy Brothers and doesn't do a very good sales job.

    • A 'Designer HTML Mockup' - These are also mockups in a Web/Windows Forms with full CSS Styling and graphic designer enhancements: An example of an pretty Designer HTML Mockup

      

      Figure: Designer HTML Mockup - not recommend because it is time consuming to make changes (which is what you are doing at the beginning of a project)

    • A 'Designer Photoshop Mockup' - These are concept mockups in Photoshop providing a guidance of the final look with full styling.
      Don't go down the track of giving a customer a few concepts - there becomes too much mixing and matching when they see them.
      Once the images are approved, then the designers slice them up and turn them into HTML
      Note: slicing is the exporting of each image:

      

      Figure: Designer Photoshop Mockup example - recommended as quick to change, when changes happen (especially in early stages of a project)

    These mock-ups should also have a notes section with the business rules that apply to the page. If there are a lot of rules then it is acceptable to link off to a word document.

    

    Figure: Good Example - This mockup states the rules that apply to the page

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/SpecificationByMockUp.aspx

14. Do you give each project a project page (that you refer customers to)?

    A project page is not a place to introduce the project. See our rules to happy clients

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ProjectPage.aspx

15. Do you conduct Market Research via the Web?

    Why write code when you may not need to write any at all? In every industry Market Research is conducted before a product is developed. Why is IT any different? Doing Market Research focuses the product on the right set of people so you can satisfy their needs. If you can't connect the dots between the work you do and how it helps the customer, consider investing your time elsewhere. Market Research bridges the gap between the techies and the users.

    A great way we get feedback on upcoming projects is by putting our specs of upcoming projects on the web and inviting user comments - not forgetting to acknowledge their contribution. Often Surfers will tell you what is needed to make the product great instead of just good, or you may be told that there is already a program out there that does the job. You should also spend two days looking for similar products and speaking to users about the features. Since the specs are full of screen captures, this allows us to think of our end-users and increases the likelihood of creating a great product which our users love.

    Who comes first? The Technology or the User? I even wonder about Microsoft, they've built this great .Net technology which works fine in Notepad but now we're waiting for the Visual Studio interface. They are going to shoehorn a user interface and experience onto the framework so the user experience is likely to be a compromise. What great products are designed this way? Do tailors measure their clients after the suit has been sewn together? I'm sure Microsoft spend heaps of time and money discussing the specs amongst themselves, but I believe they should've put the interface/Images on the web so that experienced users could voice their opinion and offer suggestions early in the product cycle. Instead we wait for the beta versions - if you offer a suggestion now, there is no time for it to be implemented as the shipping deadline is too close. The only contribution we can make at this stage is finding bugs!

    So balance engineering, business and usability, put your specs on the web, keep them updated with changes, and listen to your users!
    

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/Research.aspx

16. Searching: Know the three important sites for when you're stuck

    You've come across an error you can't fix. Do you:

    • Start coding?
    • Start thinking about how you should write the function before coding?
    • Put it off till later?
    • How should I know? - I never really analyze these things
    • Investigate to see whether someone else has come across the same problem?

    If you think about the problem, you are brighter than the average programmer. In software development it is highly possible that someone else has encountered the same problem you are trying to solve. And if so they may have even made that solution public, even better still, the developer may have compiled their solution in a very handy 3rd party utility you can download.

    This is the way in which we investigate issues:

    1. Newsgroups http://groups.google.com
    2. Search Engines (http://www.google.com is by far the best but try other search engines as well)
    3. Microsoft Knowledge Base - http://support.microsoft.com/support (Great for issues/bugs in your programs)

    This applies whenever you are writing specifications or dealing with support issues and Bugs in your programs.
    

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/Investigate.aspx

17. Searching: Do you know how to be a great Googler?

    The best developers are also extremely good at finding a solution to a problem they don't know.

    I am pretty good at Googling. When I can't find something, I ask my friend Scotty on IM. Scott Hanselman is the best Googler I know. He can find anything in 2 minutes...

    Tips:
    1. Think of a piece of the code that will be in the answer
    2. Include the company name if possible
    3. Use the advanced searching functionality
    4. Use quotation marks when you're searching for an exact string
    5. Include the technology used if appropriate

    If someone asks you for help searching, always tell them the keywords - that will help them learn to search better.

    For example, take www.smh.com.au, a leading Australian news website. If you search on the key words 'Australia' and 'news' you wont find it on the first page, but if you add 'Sydney' (a word from the company name) then you're number 1...

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/Googler.aspx

18. Searching: Can you instantly find any file on your computer or network?

    Often you will want to quickly find a file on your computer or local network. On the web, with the advances in search engines this seems so easy. New enterprise search tools are now making this same feat possible for your desktop. Your tool should index all your local files and emails, and also allow you to search your entire network.

    Using either Google Desktop Search or MSN Desktop Search will allow you to instantly search for a name and find all correspondence with that person. Even if there has been no contact for 6 months, you can resume the discussion as if it were yesterday.
    

    Follow our standard on setting up Enterprise Search

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/EnterpriseSearch.aspx

19. Management - Do you always inform your client how long a task took?

    Put 'Actual Time Taken' into your email. It's all about education and accountability - a customer that understands how long things take is better than one who doesn't.

    During the course of a Time and Materials projects, a client will often ask for an estimate on a particular piece of work. Of course we duly go about investigating the work to deliver to the client the required estimate.

    Sometimes, due to the nature of the work, the time taken to investigate is completely out of proportion to the time taken to complete the work. As an example, if you are working on a legacy ASP application with loads of spaghetti code, and the client wants a particular bug fixed, it can take 2 hours to locate the bug, and then only 15 minutes to fix it. When you report to the client the estimate for 'how long' - ensure you include the 2 hours investigation, not just the time to fix it. Thus, you need to put 'Actual Time Taken: 2:15'

    We have a program called SSW eXtreme Emails! that allows you to use Email as a task tracking, estimating and reporting tool.

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/FactorInvestigationTime.aspx

20. Management - Do you use XP wisely?

    Figure: You need to check up on your developers every 2 weeks. Then you'll never be fooled!

    eXtreme Programming is a big concept which we try to use here. I don't adhere to every idea, but there are some very practical rules I follow which improves the way we develop on large projects:

    1. Releases - Never set a deadline more than 3 weeks from the previous deadline. Deliverables become a lot easier to manage and meet when they're small.
    2. Unit Tests - Write tests before you write code. Unit Tests become a way of life and although they're expensive at the beginning, they pay off during the course of the project. To find out more about Unit Tests see Rules To Better Unit Tests and for unit tests in the GUI of SSW Code Auditor please go to Rules to Better Code
    3. Validation Tests - To find out more about Validation Tests see Rules To Better Website Development

    Here are the rules we don't agree with:

    1. Metaphors - the client description
    2. Physical Cards - emails are much better - we use SSW eXtreme Emails
    3. Pair Programming:
       • XP says 2 people at one PC - we have two developers on their own PC's sitting next to each other.
       • We fix production code in pairs. 'Too Expensive' some say. Yes it's pricey, but it's better quality.
    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/XP.aspx

21. Management - Do you have daily stand-up meetings (Scrums)?

    A tight project team should have a daily 'scrum' stand-up meeting every morning. It's held standing-up so it's short and to the point. No-one wants to stand around waffling. Three essential questions must be asked:

    1. What did you do yesterday?
    2. What are you going to do today?
    3. Do you have any roadblocks?

    Asking these questions of every project member means no-one can hide and must contribute. Further, if there is a disconnect between what was promised and what was performed, the Project Manager discovers issues quickly, the team becomes aware of progress and members are accountable for the promises they make and break. The team's successes and failures are shared, and anyone who knows the answer to someone else's problem can help with a solution after the meeting.

    Another few questions you might be interesting in asking are:

    1. Who were you working with?
    2. How long before the next 'debrief Meeting'?
    3. Do you think the client is happy?

    Figure: There is no sense in putting a Band-Aid on a patient's scraped knee if there is a big knife in his eye!

    

    Figure: Schedule a daily recurring scrum meeting in Outlook

    What happens if people are missing?

    The meeting is held with the remaining people.

    If the Project manager is not in the office for the scrum meeting then they must be conference called. If the Project manager cannot be contacted then the "Lead Developer" will conduct the scrum and send a "Scrum done" email to the team on the outcomes of the meeting.

    Note: The client is required at the stand up meeting if the project is managed by the client (ie Ad Hoc work).

    What happens when you run out of tasks?

    The goal is to be productive for 8 hours of the day, so communicate with the rest of the developers and work with them on any other outstanding tasks. If there are no more tasks then an email to the Project manager stating "I have run out of tasks and stopping work on Release X".

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/DailyStandUpScrum.aspx

22. Management - Do you send Morning Goals?

    Figure: Sample Morning Goals Email

    At SSW we email the tasks we plan to achieve that day (only!) to our client (CCing our manager) within 10 minutes of sitting at the desk, before we make any phone calls or write any emails. This ensures our clients are fully aware of the work taking place - and gives them a chance to change the priorities. It also allows us to get better at estimating what we will achieve in a day. These updates are particularly useful for off-site work and most on-site work - unless a client chooses to manage the project down to the task level, and performs daily status checks. We:

    • Forward the previous morning goal from yesterday, striking out completed items
    • Comment (in a different colour) and give the reason whether any items were not completed
    • Copy outstanding items to today's morning goals, appending any new information
    • If we are working on-site we always send our morning goals from our SSW mail account, not an internal account the client may choose to give us. This enables us to keep a record of the email, and also keeps the branding consistent. If this is not possible, we always CC our SSW account (and then move the emails into your "Saved Items" when you get back to the office)
    • If something more important arises during the day, we note it down on the next days morning goals.
    • If a task is huge (e.g. clean up my email inbox) and we only aim to do a portion of it, we say so in the morning goals as well.
      

      

      Figure: Morning Goal Item with a mini goal (140 emails)

      
      

    Note: You can use SSW eXtreme Emails! to send morning goals automatically.

    Morning goals should be sent to the client, CCing the people you are working with. If working internally, the client is your boss or product manager.

    We no longer do this, we now do our daily stand-up meetings (Scrums) because it is more effective with interactions between team members.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/MorningGoals.aspx

23. Do you allow users to check for a new version easily?

    It is important to give users the ability to check for a new version of the application they are using. And once located it should be easily downloaded and installed. We place:

    1. A tick or a cross on the main menu
    2. and a "Check for Updates" option in our Help menu.
    
    Remember:
    • This is mainly for Windows Forms, but you can do the same for new versions of Web Applications - e.g. a knowledge base package or Reporting Services Application.
    • You can do a complete check of your PC at the click of a button using SSW Diagnostics
    • Since this check occurs over the web, you should use threading to avoid slowing down the forms responsiveness. This is a generic component that is available in the SSW .NET Toolkit.
    • If the UI is a Windows Service, be aware that they don't open up the UI very often. Therefore you can't rely on this method. In a coming release Diagnostics will ask for your email and let you know when updates are available for you PC.

     

    

    Figure: BAD UI - a nagging message box that forces the User to click OK

     

    

    Figure: Show a Tick when the application is up to date

     

    

    Figure: Show a Cross when the application is out of date

    
    To keep the consistent look and consistent code, we have implemented our version checker as a user control.
    

    

    Figure: SSW.Framework.WindowsUI.VersionStatus

    As it is a user control, we can easily implement this in all our applications. We just need to place the user control on the winform, and have the ProductDownloadID and ProductLatestVersionURL entered with the correct values.
    

    

    Figure: Enter the ProductDownloadID and ProductLatestVersionURL

     

    

    Figure: Include 'Check for Updates' in your applications

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/AllowUsersToCheckNewVersionEasily.aspx

24. Do you keep the best possible bug database?

    There are 101 bug databases on the market at the moment and of course many companies make up their own in-house system. Historically these have been Access or VB apps, but the latest fashion is to use Web-based apps. Because you will use it all day long, it should be rich-client. But as your clients will need to report bugs as well, web-access is also important.

    This is a common scenario: Your tester/client finds a bug, they log on to your on-line bug database, and enter the data, they save the error message as a gif and upload the image. As Project Manager, you get notified by email of the bug, you log on to the application, view the image, review the status, assign a priority, and assign it to a developer. The developer receives the email, logs on and sets about fixing the bug. When completed, he logs back on to the application, enters a completed date, and an email is sent to the tester/client. The tester/client logs on, and is told what to test, reviews the work, enters a checked by date, and the final email is sent to the manager who closes the bug.

    Phew! That sounds like a lot of steps which is why most people resort to just sending an email. I believe most people send requests for tasks via email, if this is the case, why should developers have a separate "to-do" list, in the form of a bug-database in which they re-enter data?

    Exchange Server and Public Folders (made available on the Internet) are the best solution. The benefits are:

    • Developers are working solely from their email which they are familiar with, and don't have to switch applications when working on their "to-do"list
    • They don't have to re-enter data
    • Managers can see important information like Tasks Completed and Tasks Assigned. The reports are ASPX pages that read from Exchange Server via OLEDB
    • Clients can see what developers are working on via a URL to the Public Folder

    You can use build own solution or use SSW eXtreme Emails!

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/KeepBestPossibleBugDatabase.aspx

25. Do you log every error?

    Figure: Log every error!

    When you walk into a clothes store to exchange a pair of jeans, you expect to be treated with respect. The sales person should talk to you at your level, deal with your issues, and in a polite and fair way handle your problem. Why do Developers think they can treat their users so poorly?

    Every error message you put into your products is an opportunity for good service. Users don't want to see "Run-time error. Can't save record with zero length string" The User will receive messages that help them through the situation.

    Not to say though that there is any ideal error message - a great error is one that has been eliminated! We believe that every unhandled error is our fault - not a user error. We weren't smart enough to ensure that the user would never encounter this problem. It could be we failed to create the right interface, we wrote sloppy code or that we didn't test well enough.

    In the old days we used to store unhandled errors in a local Access db, but in the connected world, to ensure that all unhandled errors are dealt with as quickly as possible, SSW applications now automatically email unhandled errors to our Exchange Server. This is a proactive and polite approach of dealing with unhandled errors. If it's serious we will contact the client to resolve the situation - they get a bit of a surprise and think we have ESP!

    Remember what it is like to have good service in a restaurant. A good waiter knows when to interrupt you, when to leave you alone and how to do it all in a courteous and respectful way.

    At SSW all errors are caught and emailed to support@s*w.com.au. (Note: Please change "*" in "s*w" to a "s") They then go into a public folder 'Support' where a web service logs the error into a database.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/DoYouLogEveryError.aspx

26. Do you provide your users with Diagnostics (aka refactor tools?)

    We recommend adding these menus to your Tools Menu:

    • Tools - Validate Schema (with SSW SQL Deploy)
    • Tools - Validate Data
    • Tools - Run Unit Tests (with NUnit)
    • Tools - View Application Errors (with SSW Exception Logger)
    • Tools - Validate PC (with SSW Diagnostics)
      
    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ProvideUsersWithDiagnostics.aspx

27. Management - Do you fix bugs first?

    This rule has been important to me for a long time. Fix bugs before adding functionality. There are a number of reasons the most important is that bugs get more expensive as they get older. This is important because, in general, a bug will be more complex to fix the longer you wait to fix it. And it's far better to get the developer who created it to fix it while it's still fresh in their mind.

    If there isn't a rule 'Bugs first' then too many developers have a tendency to focus on the new 'interesting' functionality, than fixing that bug they left yesterday...

    There are other pressures like the project plan is behind schedule or the client is telling you that they want this feature added, and leave the "bug fixes" in the existing code till later. This is a deadly mistake. At SSW we always fix known bugs first.
    

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/FixBugsFrst.aspx

28. Do you Re-factor?

    What about bugs that aren't really "bugs"? An example could be an incorrect naming convention, or a spelling mistake in a folder name. At some point in the future this is going to cause a headache. Developers are going to have to factor in this error meaning errors will be built on errors.

    What do you do when you see a directory structure like this:

    • SSW/Images
    • PDI/Images
    • ABC/Image
    
    
    1. Leave it, it is only a little inconsistency after all, and fixing it may cause some bad links and why fix something that isn't broken?
    2. OR fix the inconsistency straightaway?

    For me the only answer is b). Tackle these problems head on, in line with the fourth principle of eXtreme Programming - courage. Fix the problem now and save it from becoming a bigger problem later.

    The best way to keep consistency is to use 'Lint Testing tools'. When you find lint on your jacket, your jacket doesn't stop working, but you fix it anyway because you care about how you look and the impression you give. You should treat your code the same way. The "lint testing" tools I use are Code Auditor, SQL Auditor and Link Auditor.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/Re-factor.aspx

29. Do you 'zz' old files?

    When you are regularly creating new releases of a cool .NET application or simply producing new proposals in Microsoft Word, files will inevitably become outdated. At SSW we are aggressive in killing any unused files. Rather than hit the DELETE key we put a 'zz' at the front of the filename. The old versions should not be deleted straight away - it is just an unnecessary risk!

    

    Figure: Include 'Check for Updates' in your applications

    

    Figure: 'ZZ' your files rather than deleting them!

    Note: Other systems are used that are less aggressive than our 'zz' rule.

    • In .NET, the keyword obselete is used to mark types and members of types that should no longer be used - these then turn up as a compiler warning.
    • In HTML, the keyword deprecated is used.

    Both allow for some backward compatibility. If you want to pussy foot around then do this, then later 'zz' the files.
    See our Rules to Better SQL Server Databases - Do you add zs prefix to table name?

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ZZOldFiles.aspx

30. Do you know the best way of managing recurring tasks?

    Recurring tasks are tasks that happen on a regular basis, but not necessarily every day (and therefore potentially easy to forget!)They might be personal tasks, such as changing the oil in your prized Datsun 120Y every six months, or booking a holiday for you and your partner a month before your anniversary. They could be work related tasks, such as updating your profile on the Microsoft Gold Partner website (every three months), running financial reports on a monthly basis, or even watering the office plants every week.

    Now managing those tasks can be difficult. "Just stick an appointment in Outlook" - yes I've heard and tried that method. Outlook is perfect when you are the one performing the task. But it's nowhere near perfect if you're managing people who are allocated to perform the task. In fact it's a disaster, because when that person leaves, (or just changes job role) that scheduled task/reminder disappears with them.

    The other problem with Outlook is if you are an organization that relies upon email as a to do/task list, Outlook doesn't send an automated email.

    After reviewing a few different options, we decided using Google Calendar to manage recurring tasks was the best option.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/BestWayOfManagingRecurringTasks.aspx

31. Do you always fix it - or at least report it?

    Are your Quality Assurance standards clearly understood? In the course of development and testing, programmers will often encounter bugs or problems. How do you deal with these? You can either:

    1. Pretend you didn't see the problem
    2. Fix it on the spot
    3. Report it so someone else can fix it

    The best solution is to use a combination or 2 and 3. If it's a small problem (less than 15 mins) you should fix it on the spot. If it will take more time, you should email the issue so someone else can fix it. While this can cause unforeseen delays, it's better to get 2 things done at 100% than get 4 things done at 75%! This way of approaching problems ensures that errors are not forgotten.

    The question is whether you use the 'Tree Approach' to problems or the 'Straight through to Goal approach'. In the Tree Approach, you branch away from your main task and do 2. and 3. when you see a problem. In the Straight to the Goal Approach you do 1. and only work on your primary task. At SSW we try to balance short term productivity with long term improvements to our website products and processes; We use the Tree approach - although as a minimum you should at least report issues that arise.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ClearQAStandards.aspx

32. Do you conduct an internal "test please" prior to releasing a version to a client?

    Does the Test Please principle apply to more than code?

    Yes! a test please, aka peer review highlights unseen errors, proposes new ideas for consideration or confirms the existing work as the best solution. A peer review can also effect cultural change amongst your development team as developers become more open to critiques of their work and comfortable with a 'continuous learning' environment. A "Test Please" will also be applied to:

    • Brief proposals
    • Release plans
    • Estimates
    • Anything else being sent to the customer

    Test, test, test! Testing is the most critical part of any project. Before the delivery of any release the application must pass an internal "test please". Clients quickly become disillusioned if you have delivered a bug-riddled application.

    There are a number of different types of tests that you can perform:

    • Unit Testing - the smallest testable part of an application that validate the individual units of source code are working properly. Unit tests does not cover the UI layer and there is no industry standard 3rd party tool to perform this task.
    • White Box Testing
    • Black Box Testing
    • Integration Testing
    • User Acceptance Testing (UAT)

    Developer responsibilities
    

    1. At the end of a release prepare a "Test Please" email. (You can use eXtreme Emails to do this)
    2. Have 2 experienced testers to test, the second tester will only test after the first tester has finished testing and given it a pass
    3. Specify exactly what is required to be tested. Be specific e.g. run Timesheet report
    4. Triage emails as they come in for completion in this release, or a later release
    5. Keep a schedule of testers changing them only on a release by release basis - never change testers within a release
    6. Delay the build until the testers have replied DONE. It is possible to proceed with a build even with a test fail if the bugs existed in the previous version and they are being worked on
    7. Randomly have the manager do a "Test Please" as well. He gives a pass or fail on the job the testers did. If the testers didn't do a good job, they stay on the schedule and test next time
    8. When you receive a "Test Please Succeeded" from both testers (and never before) prepare a "Test Please" for the client. (If you are requested to issue a non-tested release to a client state "Has not passed internal testing" in the email)

    Tester responsibilities

    

    Figure: Do you want users to have good first impressions?

    1. Confirm you are a tester - If the developer did not name you, make sure he corrects himself and resends the 'test please' email.
    2. Ensure you are working on the Standard Operating Environment specific to the client
    3. Use Team Viewer if you aren't available locally
    4. Test within the hour - testing is typically urgent
    5. Know what to test - The areas requiring testing should be specified in the email, test the whole application if not specified
    6. Be thorough - anything from a crash-to-code bug to a minor UI change should be reported (one email at a time)
    7. Classify issues accordingly to "this release" or "next release" following the report bug/enhancement standard so the manager can triage requests correctly. Any crash to code bugs must be fixed in the current release. The project manager may override your prioritisation.
    8. "Reply to all" for each bug or feature (to ensure no issue is reported twice)
    9. Specify how you replicated the bug through clear instructions and screenshots
    10. Use SSW eXtreme Emails to reply to the 'test please' email with "Test Please Succeeded (as no Critical bugs)" or "Test please failed (as per critical bugs reported)"

        

        Figure: This is how to reply failed to a "test please" email

    Note 1: View a sample Test Please Report that we use for all development. This report gets automatically generated with our tool, SSW eXtreme Emails!.
    Note 2: As 64bit platform has been quickly adopted, testers should consider to test the application on 64bit platform, these will include Windows Vista x64, Windows Server 2008 x64.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/InternalTestPlease.aspx

33. Do you know the 4 steps to do a "Test Please"?

    The client agrees that prior to a version being submitted to the client, the SSW developers will:

    • Perform automated testing with SSW Link Auditor (for Web Apps)
    • Perform automated testing via Unit Tests
    • Perform an internal "Test Please" (aka "Alpha Testing" eg. only that pages or forms load, not checking the business rules)
    • Then send a "Test Please" to the client (aka "Acceptance Testing" to check the business rules)
    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/TestPleaseFourSteps.aspx

34. Do you Reward your developers for completing a release on time and budget?

    When your team has completed a release successfully, they should be rewarded with a morale boosting event!  Each team member is provided with a budget of $50 for use at a communal event e.g. lunch/dinner/cinema/bowling.  The following conditions must be met:
     

    1. Budget - the release must be completed within the budget allocated
    2. Scope - no more than 50% cut-out in items (count the work hours removed compared to the original total)
    3. Quality - must pass test please and get a mark of 7/10 or above from the client
    4. Time - the release cannot be delivered 50% over time e.g. if the planned finish date was 14 days (two weeks) after the start, then the release must be delivered less than 21 days after the start date
    5. Release debrief - sent to the client and completed and a review of "Rules to better project management" by the project manager
       

     

    Subject: "Release completed on budget and customer happy - reward!"   New, Release - on time Done.  Release was handed over on the deadline. Release - on budget Done. The release was fixed price Scope - no more than 50% cut-out in items (count the work hours removed compared to the original total) Done.  No items were cut from the release plan Quality - must pass test please and get a mark of 7/10 or above from the client Test please passed.  The client assigned 8/10 Release debrief to the client to be completed Release debrief completed.  Rules to better project management reviewed.  Greater visibility of progress would be beneficial and remote access to staging server during development.   Our team will be celebrating our success by going for lunch. Developers, Congratulations on completing the project on time!  We will celebrate by going for lunch together at Bistro Paris on Friday!  We have a budget of $50 per team member! Robin, If you are available it would be great if you could join us.  Meet at the SSW office in Neutral Bay at 12:45pm.

    Figure: Email to accountant/team members and client informing of release success and reward event

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/RewardDevelopersForCompletion.aspx

35. Do you have a Knowledge Base (KB)?

    Do you know what the most useful thing on Microsoft web site is for me? It is their knowledge base at http://support.microsoft.com/support When I have a problem it is my first port of call - it allows me to help myself. So, if you answer questions on your products to customers, you are wasting time if you don't have a knowledge base. Just think, you might not be answering Harry's question if he could have looked it up himself. Now of course there are many customers who don't look for a KB, but instead you fire off the same old email that you already know is an MDAC related error, and your current solution is to tell them to run SSW Diagnostics and get all the green ticks. The basic rule is don't send back the answer in your email - instead send back the link. More specifically:	Dear Harry, Thank you for taking the time to report the issue for SSW Code Auditor. I'm happy to let you know that this is a known issue and has been addressed in our knowledge base. Please see http://www.ssw.com.au/ssw/KB/KB.asp?KBID=Q260000 for details. Kind Regards,
    	Figure: Responding to a known issue with a KB article

    If you can answer a support email then reply to the support email (using one of the 4 templates on the right) TO: the client CC: the developer and your manager with the KB link If you can’t answer the question then reply to the support email TO: the client and the developer CC: your manager Ask the customer if they can get diagnostics to all green ticks. Ask the developer to “Please action?" Notice how by just giving them the URL, this email does the job of encouraging them to use your knowledge base in the future. You need to make sure the support staff know that there are really only 4 types of emails customers should be receiving (see the 4 grey boxes).
    		Dear Harry, Thank you for taking the time to report the issue for SSW Code Auditor. I am sorry to let you know that I cannot reproduce this. Could you please provide me more details, or even better would I be able to connect to your PC - it is simple and you can see everything I do. To do so, you can send me an appointment for an appropriate time or add me your MSN Messenger, my address is xxx@s*w.com.au P.S. Don't forget to run SSW Diagnostics, ensuring that you only get green ticks. Kind Regards,
    		Figure: Responding when you cannot reproduce the issue

    Things are running well when you have support staff adding new KB for: Known issues Hot tips Performance tips KBs also play a very important role in getting a product released. You will never get every feature done or bug fixed - we all know it. Focus on getting a version out. It is usually more important to have a version available than having no version at all. When you are looking down the Project Plan, decide on what the MUST HAVES are. The others features and known bugs will have to remain outstanding. All the longer term bugs should go into the KB. We also put in the feature requests that we plan on doing. This way our customers know of our exciting features coming in future versions of our software. However DON'T write a KB article if fixing the bug and making a new version solves the problem. You'll have to fix the problem anyway, so don't waste time writing a KB, just email the new version. Please see How to Develop and Reply "Done"	Dear Harry, Done. The code changed from xxx to yyy Thanks for reporting this bug - our software gets better with help from every customer like you. This fix will be available in the next version shortly. Stand by, you will be notified. Kind Regards,
    	Figure: Informing of a Fix (Email 1 of 2)
    	Dear Harry, Thank you for taking the time to report the issue for SSW Code Auditor. I'm happy to let you know that this problem is fixed in this release. Please download the new version at http://www.ssw.com.au/ssw/download I welcome more feedback it really helps. P.S. Don't forget to run SSW Diagnostics and gets all green ticks www.ssw.com.au/diagnostics Kind Regards,
    	Figure: Informing of a New Version (Email 2 of 2)
    You don't need to be Microsoft to build a KB. A Knowledge Base does not need to be complicated. We use a simple knowledge base which is located at http://www.ssw.com.au/ssw/KB

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/KB.aspx

36. Do you know the best way to give the best customer support?

    There are a few methods to control a client's machine remotely, all of them have the same functionality, but different usage, and different pros and cons. First, you need to know whether that's a server running server OS (eg: Windows Server 2003), or an end user machine running workstation OS (eg: Windows XP).

    For server machines, we recommend using either Windows' built-in Remote Desktop (also knows as "Terminal Services" in Windows 2000) or VNC-based tool. Remote Desktop provides each authenticated user a Windows logon session that is not shared, if your client lives in a place where the time zone is different, Remote Desktop should be your first choice as it doesn't need the client's interaction once Remote Desktop is enabled (typically it should have been enabled for a server for the ease for remote maintenance and monitoring).

    

    Figure: Enabled Remote Desktop

    Note: Remote Desktop works for workstation OS too, but it's not recommended as it might leave a security risk on client's machine afterward if client forgets to disable it. Most users don't need Remote Desktop to be enabled. Also, because of the End User License Agreement (EULA), XP only allows 1 user at a time, if you log on to client's XP machine, the client will be logged off.

    
    

    TeamViewer allows you remote to client almost the same as Remote Desktop. Furthermore, client can see what you do on his PC because you use the same session. Another functionalities will assist your supporting, you can chat with client in TeamViewer and transfer files to client's desktop.

    
    

    For the VNC-based remote tool, one of the main difference of VNC-based remote tool is it shares the same logon session with the user who is currently logged on the machine. The server administrator doesn't need to give us the Windows' username and password nor create a temporary user account for us. And because of both parties will share the same logon session, we see what the clients see, and so do they. Some clients may prefer this as they know what's happening exactly, which is important for a server.
    The VNC tools we prefer: TightVNC and UltraVNC.

    
    

    For supporting end users' workstation machines remotely, here is the order you should try with the end users:

    1. Remote Assistance in MSN is what you try first. It will work unless the user is behind a firewall or router.
    2. Remote Support in TeamViewer, it’s so easy and simple and works in most environment.
    3. Your second option is to try UltraVNC SC - there is no screwing with firewalls at client side and it is free.
    4. The final option is to try Copilot - there is no screwing with firewalls at both sides. Only downside is it is not free.

    See following standards:

    1. How to use MSN for Remote Support
    2. How to use TeamViewer for Remote Support
    3. How to use UltraVNC SC for Remote Support
    4. How to use Copilot for Remote Support

    Here is a sample script you can follow: SSW Remote Support Standard

    See useful tools The Best 3rd Party Network Tools - TeamViewer.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/RemoteSupport.aspx

37. Do you always install latest updates when you fix someone else's PC?

    When you fix someone else's PC (locally or remotely), one of the best practices is always make sure it has the latest updates.
    
    To achieve this, we run Microsoft Updates (not to confuse with Windows Updates) and install all latest updates for all the known Microsoft products.
    Note: "Windows Update" only updates the operating system, where "Microsoft Update" updates other products as well, such as Microsoft Office, SQL Server, etc.

    

    Figure: Microsoft Update (Good - all updates are installed)

    
    Next, install SSW Dianostics and check the latest version of other applications are installed.

    

    Figure: SSW Diagnostics (Good - all updates are installed)

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/FixPCUpdates.aspx

38. Is a Back-end structural change going to be a hassle?

    Why don't most programmers plan ahead? Take an average VB or Access application that you sell to a few customers. When the customer wants a new version, there is no problem giving the customer the new mdb or exe. But what if you made a back-end structural changes to your database? Big hassle! You need to compare the database to remind you what was changed. Sure there are utilities for this - for Access backends you can use SSW Data Renovator or for SQL Server backends there is Red-gate SQL Compare - but why go to this trouble.

    Take a version control approach. It doesn't have to be too complicated, but you should keep a history of structure changes in a table. Some developers use a text file (.sql) or hardcode it in code, that's fine, just don't make changes in the interface (i.e.. Access or Enterprise Manager). Changes should be made programmatically, or in a method that they can be played back.

    An assumption to this is you have a front-end and backend table that is used to record the version number.

    

    Figure: Never make a change manually in Enterprise Manager or Access

    

    Figure: Always save your changes in script

    

    Figure: Name them in the order they're executed

    

    Figure: An example of a backend table recording the version numbers

    Tip: If you’re using Next Gen and you’re changing just one table, then just regenerate for that table

    We have a program called SSW SQL Deploy to solve this problem and automatically make schema changes.

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/Back-endStructuralChange.aspx

39. Do you have separate development, testing and production environment?

    It is important to maintain three separate environments for development, testing and production. Some companies skip the testing server because it can be a hassle to copy new files, register DLLs and deploy backend changes. This will usually result in higher support costs and unhappy users due to simple bugs that could have being found in testing.

    The best solution is to use build scripts (.bat and .vbs files) to automatically create a setup package that can be used to deploy to testing and production environment. For backend changes, you can either include the change scripts with the setup package (if it's localised database), or run those scripts as part of your deployment process.

    Read more about setup packages at SSW's Wise Standard for Products.

    Now make each environment clear.

    Whenever an application has a database, have a visual indicator. I recommend a different background color for each environment

    • Red for the Development database,
    • Yellow for the Test database and
    • Grey (no colour) for the Production database

    Note: The Yellow might have been Orange (kind of like traffic lights) but the color palette in Word doesn't give Orange.

    

    Figure: colors in Word color palette

    This prevents testers from accidentally entering test data into production version.

    Windows Forms Tip: Implement in the base form in the header
    ASP.NET 2.0 Tip: Implement in the master form in the header

    

    Figure: Spice up your environments with different colors

    An application of this rule is how we identify our CRM servers - see rule Do you identify Development, Test and Production CRM Web Servers by colors?

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/SeparateDevelopmentTestingAndProductionEnvironment.aspx

40. Is everyone in your team a Standards Watchdog?

    "An ounce of prevention is worth a pound of cure" goes the saying. Having a strict coding standard is prevention. To create good code you must have good standards, such as commenting standards, naming standards, versioning standards and more.

    To: Peter CC: Adam (Manager) Dear Peter While you were away, I came across a page called ApplicationForm.aspx which was giving an error: 'The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.' This happened when I entered '13/06/2002' into a the 'Start Date' field of the form. The error occurs because you are not using the default language of the server which is 'English' - for the users of this database FRDC. This is the same as US English format of Months first, then Days, then a four digit Year (mm/dd/yyyy). Instead, you used 'British English' on the FRDC database which has a format of dd/mm/yyyy. Please use the standard as per Rules to Better SQLServer Databases, Rule 1200 (Middle Tier Section) Please note that whilst inserting data from your Front End application, you should not use the format dd/mm/yyyy. Instead you should use yyyy/mm/dd Let's fix it together when we get to work tomorrow. Cheers, DDK

    Figure: Make sure you let your client know you find a standards violation

    
    Every member of a team plays important role in maintaining standards. Whether it's my code or someone else's, I always keep an eye out for mistakes.

    When I come across an error, I never just fix it, as the developer who made it is likely to make it again. I write an email to the person explaining what has been done wrong and how to do the right thing. I CC the manager so they are aware of the situation.

    Of course, with everyone doing this in the office, it's not a matter of finger pointing, we all truly work together to write better code.

    When you notice someone doing the wrong thing
    • First time just send an email with a pointer to the rule
    • Second time, have a very quick chat with them
    • Third time call them in and give them a formal talk about it

    If you don't have the confidence to talk to the person, send an email from info. The important thing is to talk about it at the time. 

    Clearly, this standard does not just apply to writing better code, it applies to all company standards. Standards are important because they ensure your experience at work is consistent and enjoyable. For example, if there was no standard to stack the dishes in the dishwasher when you were finished using them, dishes would build up and create a big mess in the kitchen!

    Equally important is your responsibility to ensure that others are doing their best to maintain and follow the standards.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/StandardsWatchdog.aspx

41. When you follow a rule do you know to refer to it (including the icon)?

    

    Good Example

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/FollowARuleAndReferToItIncludingIcon.aspx

42. Do you thoroughly test employment candidates?

    Do you rely entirely on the claims of Recruitment Agencies when selecting new employees? If you do, it may be a very costly mistake. I have been giving coding tests to new employees for 10 years. A candidate has to prove they can walk the walk before they can join our team.

    I give a Project Management test to coders as well. I want my coders to be able to contribute to the working of a project from end to end. They need to be able to communicate with not only sales and marketing staff, but also clients and people that walk off the street! Clients typically think developers (aka computer nerds) come from another planet. Getting Project Managers at the go between is good, but on many jobs it just adds a layer and an unnecessary cost to a job. Recruiting developers that understand the ins and outs of project management means that that developers have less reliance on a Project Manager, they get to speak to customers more (a very good thing) and the customer gets a cheaper solution.

    Another thing is that when interviewing you have to go on your instinct a bit. This won't always work, but as Joel says, "a bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs." It's best to let a good candidate slip occasionally than let a bad one spoil your coding and client relationships. Joel again: "If you have any doubts whatsoever, No Hire."

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/TestEmploymentCandidates.aspx

43. Do you have a healthy team?

    Developers are notoriously unhealthy people. They don't exercise enough, don't sleep enough and eat the wrong food. An unhealthy developer is not going to be able to concentrate or put in the hard-yards when required, nor are they going to be very happy. In the office I try to look after them as best I can by:

    • Not having chocolate biscuits and instead keeping a bowl of fruit
    • Not having coke machines and instead having a purified cold water bottle in the middle of the office
    • Encouraging them to do as much exercise as possible - even doing push-ups every day.
    • And instead of dinners for birthdays where you eat and drink all night, every few months we always do something fun for someone's birthday, like indoor climbing, ten-pin bowling or even a bush walk in the Blue Mountains.

    I also conduct a monthly weigh-in, with incentives to look after yourself. I don't encourage my developers to stay up all night investigating new stuff, and I take them away for a two weeks every year to work by the beach and get some fresh air into their system, as well some early morning swims.

    I find that encouraging a healthy life-style really helps my team be more productive and have more fun.
    

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/HealthyTeam.aspx

44. Do you deal with distractions?

    Keeping your mind on the job is so important if you're trying to solve a bug and finalising a task to meet this afternoon's deadline. These are a few practical suggestions which are standards in the SSW office to help me keep "in the zone"...

    1. Program the XP way - programming in pairs means you won't cruise the web or play Solitaire, you'll be forced to focus
    2. Don't interrupt people unnecessarily when they're working - create comprehensive standards for people to refer to
    3. Avoid multi-tasking as much as possible, don't open one email, respond to half the questions, and then open another. Complete the first, and delete.
    4. Set your Browser default to "About:Blank" so you don't get distracted by msn.com
    5. Minimise Outlook distractions
    6. Minimise MSN Messenger distractions
       
    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/DealWithDistractions.aspx

45. Do you always carry your Tool Box?

    Figure: St. Bernards are known for rescuing lost mountaineers, bringing life saving provisions

    Microsoft tools are the most important tools I have. I spend most of my time using Outlook, Visual Studio .NET, SQL Server Enterprise Manager and Access. However Microsoft tools don't do everything I want to do. Rather than spending my time recreating the wheel, I am always on the look out for non-Microsoft options or extensions that will save me time.

    Not only software, carrying your own hardware and peripherals will save you hours one day: network cables, cross-over cables, wireless cards, blank CD's, blank floppy's, software CD's, screw-drivers, even a text book or two. We have one guy in our office who carries two bags, each weighing about 10 kgs. He is the SSW St. Bernard!

    A spanner might get a plumber through 90% of jobs, but he'll get stuck on the last 10% if he doesn't carry anything else. I carry these tools in my Tool Box every day. I hope you find them useful.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ToolBox.aspx

46. Do you use an Internet/Intranet for sharing common information such as Company Standards?

    Employees need easy access to standards that are used everyday. We maintain standards at SSW for any activity that can be standardized including coding practices, naming conventions, standard form layouts and documents. There are also internal standards like expense and leave procedures.

    The first step is to use HTML rather than MS Word documents.

    The second step is to think about location. Should it go on a Web site or Intranet? We believe in dividing it up into 2 groups:

    • Public - e.g. /Standards
    • Private - e.g. /Standardsinternal
    The benefit with standards on the Web is to get feedback from other developers. See our SQL Server Naming Standards for an example.

    The third step is to decide on a web page theme so every page is consistent. I am continually surprised at how much time is wasted by managers explaining to web designers the corporate template - so get smart and do one up that they can follow.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/InternetOrIntranetForSharingCommonInformation.aspx

47. Do you know the best CMS solutions for your Internet/Intranet?

    The forth step is to decide on the CMS solution. The main choices are:

    • www.DotNetNuke.com
    • Microsoft SharePoint 2007
    • www.CommunityServer.org
    • Microsoft ASP.NET 2.0 hand coded pages

    There are pros and cons to all and it depends on what functionality/customization you need but we lean towards DotNetNuke and SharePoint for most solutions.
    See DotNetNuke and SharePoint Development - The leading CMS Solutions.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/BestCMSSolutionsForInternetOrIntranet.aspx

48. Do you manage your email?

    Having hundreds of emails in your inbox is not uncommon. But it's very uncommon to find people who successfully manage their inbox. Instead they let their inbox become a great black hole with no business value. Email has a bad name in business primarily because people don't treat email correctly. Email can be a vital tool to your company, and your software development project, but it has to be managed. Here's a series of rules that govern how we use our Inbox.

    We also use SSW Exchange Reporter.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ManageEmail.aspx

49. Do you manage your papers?

    It is common during the course of a project to assemble a pile of papers of notes and other information related to the client you are working with. Some of these will be tasks that relate to the project, some will be general information that does not require any action, and some will have no use. In any case, it's important that you don't lose anything that may be needed later.

    At SSW we use the following system for managing papers around the office: All SSW staff are allocated a physical inbox. You must check it daily to ensure that is is kept empty - this is where papers relating to your projects will end up.

    1. Paper is related to a task:
       • Send an email to yourself with 'Note to self' in the subject line, and the task in the body.
       • Throw the paper away.
         
    2. Paper has no use:
       • Throw the paper away! Examples of this would include your own notes that are no longer relevant.
         
    3. Paper is not a task but needs to be kept anyway:
       
       • The SSW filing system is split into 3 categories: current clients, past clients and SSW internal. It is your responsibility to make a new folder if one doesn't exist for your client (filing supplies and the label maker are in the machine room). Write the ClientID and your initials and date in the top right hand corner of the paper. e.g. HOED - CA - 11/11/2000.
       • Hopefully any papers you may have will be related to current clients. Paper in this category include Non Disclosure Agreements, and Terms and Conditions. File the paper in the clients folder.
    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ManagePapers.aspx

50. Do you treat freebies as real customers?

    In the course of business I often provide some services or products to selected customers free of charge or at a discount rate. Often because you're waiving one rule (the "please pay me" one!) you waive all your normal rules of service. This is a very bad habit for two reasons:

    1. Freebies/discounts need just as strict controls as regular projects

       When you are giving something away at a discount or for free you are expecting a loss compared with a regular client. If you fail to follow regular processes not only will you incur an even greater loss you provide a lesser standard of service and put greater risk on the success of the project.

       A discount or freebie should follow all the standard processes such as:
       

       • initial meetings
       • written contracts
       • specification reviews
       • release plans
       • morning goals
       • triaging additional items
       • release debriefs

    2. Feedback on service

       Often the people you choose to provide a freebie are the best people to provide feedback on your product or services. When you waive all your standard processes, they have no opportunity to review how you conduct your business. So if I'm offering a freebie (or any discount), I ensure every normal standard of business is followed (including sending $0 invoices!) and I ensure I get valuable feedback to help me run SSW better.

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/TreatFreebiesAsRealCustomers.aspx

51. Do you avoid reviewing performance without metrics?

    Figure: An example from SSW LookOut!

    If a client says "This application is too slow, I don't really want to put up with such poor performance. Please fix." We don't jump in and look at the code and clean it up and reply with something like "I've looked at the code and cleaned it up - not sure if this is suitable - please tell me if you are OK with the performance now"

    Instead we:

    • Ask the client to tell us how slow it is (in seconds) and how fast they ideally would like it (in seconds)
    • Add some code to record the time the function takes to run
    • Reproduce the steps and record the time
    • Change the code
    • Reproduce the steps and record the time again
    • Reply to the customer. "Was 12 seconds, is now 8 seconds."

    This is because performance is an emotional thing, sometimes it just feels slower. Without numbers, a person can not really know for sure whether something has become quicker.

    For sample code on how to measure performance for windows application form, please refer to rule Do you have tests for Performance? on Rules To Better Unit Tests.
    

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/NoPerformanceWithoutMetrics.aspx

52. Do you ring a bell or similar when you secure a big deal, make a sale or get some great feedback?

    A great way of motivating your staff is to have some form of recognition in place; happy employees are good employees! One of the simplest ways to achieve this is by having a bell located within the office for employees to ring when they have made a large sale, secured a big deal or some important news to announce. By showing appreciation to your employees you encourage all your staff to perform.

    At SSW whenever a big new project is signed up or we sell an enterprise license for one of our products we send an email to all staff and then ring the bell, which is located in the middle of the office.

    

    Figure: We send around an email like this and ring the bell when we get good news!

    Similarly, when we get some feedback we will send around an email, and store the email in a public folder.

    

    Figure: Store your feedback in a public folder

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/RingBell.aspx

53. Do you check your code by Code Auditor before check-in?

    SSW Code Auditor is a tool to keep your code healthy.
    If your project on TFS hasn't been checked by Code Auditor and you don't want to spend time on passing all the rules, you can check your code bit by bit. Make sure every file you check in TFS has passed Code Auditor check. Then you can enforce our standards on the project step by step.

    See Do you run SSW Code Auditor?
    See Do you Add SSW Code Auditor, NUnit and Microsoft FxCop project files to your Solution?

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/CheckCodeByCodeAuditorBeforeCheckIn.aspx

54. Do you know you should always use a source control system?

    You should always use a source control system! SSW uses and recommends Team Foundation Server (TFS). Source control allows the tracking of changes to code. As well as a backup of your source code, this is very useful when debugging and fixing errors to locate changes that have been introduced.

    SSW Rules to Better Source Control

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/UseSourceControlSystem.aspx

55. Do you know what to look out for when signing legal documents?

    Make sure there are no specific damages mentioned in any legal document. They should always be left to the relevant courts to decide.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/LookOutForSigningLegalDocs.aspx

56. Do you ask clients to initial your work?

    

    Figure: A signature can be very valuable but sometimes hard to obtain

    A persons signature is extremely valuable. Getting a signature is hardwork. Sales people use all sorts of euphemisms to avoid that confronting request: "if you could just sign here..."

    However, requesting a signature (or just an initial) on non-contractual type documents, especially screen-shots or data-schemas, is very beneficial. When you ask a client to 'review this screen mock-up' they will generally take a cursory glance, perhaps make a comment or two and then move on to something else. Asking them to then initial the print-out of the screen mock-up always makes them take a second or third look, ask someone else, or at least spend a few more minutes working out whether it's correct.

    Training clients to continually review work carefully leads to more better quality work.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/AskClientsToInitialYourWork.aspx

57. Do you always try and work in pairs?

    

    Figure: Do you always try to work in pairs?

    There are many good reasons why it's better to work in pairs.

    • Less time stuck on a problem - you have someone familiar with the project to help you work through the problem
    • Your code will have less strange workarounds - because if something doesn't add up to a developer, he has someone to ask
    • Cleaner code - because you know someone else is going to be looking at your code
    • Support - when you need changes down the track, you have 2 people to call on

    But I don't promote classical pair programming which is two developers on one machine. At SSW we use our own type. We do put our developers in pairs, but they each have their own computer.

    It's also a good idea for non-programmers to work in pairs. You can keep each other motivated, there is always someone to help if you get stuck, and you absorb knowledge from each other. Experience shows that developers are more productive this way.

    If you are not sitting next to a person working on the same project, then fix it. If you can not then at least mention it to your manager.

    Is there an Overhead?

    Some projects are done quicker with 2 people - especially when they are complex. But on most projects there is an overhead, because of the extra communication between the developers - you now have to please someone else - not just yourself.

    We generally estimate the overhead as 20% extra. But this is more than offset by the cleaner code and better solutions that come from two brains working together.

    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/WorkInPairs.aspx

58. Do you perform migration procedures with an approved release plan?

    A migration from one technology to another is a process fraught with danger. Everyone would love the "upgrade" button to work perfectly but it doesn't. Expect any migration to fail first go. Any statement that "I didn't expect to have any problems" shows inexcuseable ignorance.

    A release plan for a migration will typically include:

    1. Business purpose for migration
    2. Test migration
    3. User Acceptance Testing of the test migration
    4. Rollback procedure
    5. Decommissioning procedure

    Approved release plans are mandatory for a migrations such as:

    • Exchange Server 2003 to 2007
    • ISA Server to a hardware firewall
    • Phone system to VoIP
    • etc
    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/PerformMigrationProceduresWithAnApprovedReleasePlan.aspx

59. Do you know you should always refer to rules instead of explaining it?

    When a new programmer on your team needs to get up and running on the SharePoint image you know the right and wrong way to say it

    Sit with John Liu and he will get you up on our SharePoint image

    Bad Example: Explain how to run on SharePoint image

    Get the URL to the standard from our intranet, if the standard is unclear, check your changes with John Liu and then make them

    Good Example: Refer to SharePoint rules

    
    *Note: Moved to http://sharepoint.ssw.com.au/Standards/Management/RulesToSuccessfulProjects/Pages/ReferToRules.aspx