How To develop a Huge Project?

I have read a lot of articles in the last 2 months, regarding project management and development. I also have my own experience in web portals, so what I did actually is integrating the good articles I have read with my ideas.

I have a huge project now, and I want to make sure that I’ll deliver this project as needed. But How?

Each project should be separated to a several parts (rather than phases, this is something else), a team(s) will be responsible of each part to make sure that all part notes are done and verified. Note that some parts will be done implicitly, like communications.

• Designing Part: As you can see, this part will be the creative team responsibility. the following are the keys to deliver your HTML pages without being notified later on that you have dome something wrong or miss some parts:

• • All pages should be XHTML validated through a known and registered website for all project parties (Developers, Creative and QA). By this, you will make sure that all teams have the same test engine for validation.

  • All HTML pages should have a top-leader-div to handle client error/success messages instead of javascript alerts (NO JavaScript alerts any more).

  • Use �maxlength� property for all HTML controls.

  • Use �label� tag for all static text that describes HTML controls.

  • Use �fieldset� tag to group similar HTML controls.

  • Use �legend� tag to describe �fieldset�.

  • Use �tabindex� property for all HTML controls.

  • Check the HTML Page size: after creative team (designer) has done with the HTML page, he should check its size with the linked *.css files. Its not convenient to have any HTML page size equal to 250kKB for example!

  • If you are designing a multi-package website with the same theme, make sure to have implement each package with the same structure for the others. This could be done by using one standard template page that will be used as standard for any future page.

  • If you deliver your pages to the developers, and your boss and/or client asked for changes, make sure to send the last version to the developers.

• Teams, Managers and Client Communication :

More than 50% of the projects that fails, because of lake of communication. Developers and Creative teams don’t communicate as needed, developers and client, creative and client, even managers with their teams or clients. This is a bottle nick! If you have any comment/note you should ask directly, why waiting for others to communicate with you, you should be the leader in communication.

Weak �following-up� is a bad practice in this point. If you have a weak skills in follow-up with someone or somepoint, you need to fix this.

Delay in sending questions requirements and needed information to other parties also is a bad practice.

To solve these issues just do the following:

• • • If you are a member of a team, then you should take an action immediately, no wasting time in waiting others to call us.

    • Follow up should be 200% guaranteed. Each member of a team should follow up his issues.

    • Prepare needed questions list daily, and send them as soon as possible, and/or make a queries list and send it by the end of the day to make sure that it’ll be read first thing in the morning.

    • Team members should have a weekly based meeting (like 15mins meeting).

    • Use �URGENT� phrase in mail communication whenever it needs, almost always .

    • Action should be taken and notification email should be sent to those who failed to stick to their tasks. Email should �cc� teams managers.

• PHP Developers Part:

If you are intending to implement your project using PHP, just read the following:

• • • Never re-invent the wheel. Try to use a tested framework (e.g Zend Framework, Symphony, cacke-php..etc), or at least build your project to be flixable to integrate with a frame work later on. If you don’t like the use of someone else framework, you can take some common needed classes and use them as plug-ins in your website, but remember that you don’t ever never re-invent the wheel.

    • Try your best to use the gettext() instead of including a language file. This will boost up the performance.

    • All uncompleted features should be disabled and/or removed from the testing version.

    • Comment, Comment and Comment. Always use a comments for libraries/classes/functions. Don’t ever write any of them without comments.

    • All errors should be handled, an email should be sent to responsible developer and his leader to make sure that it will be done.

    • All developers should be stick to a �Standard Naming Convention� document. You can find one on the web, or simply write your won.

    • If its not your first project, you should already have some libraries. What you have to do is collecting/preparing those common libraries, classes, development techniques and tools from all members in order to have standard code repository and to be used ni the all project packages.

    • Never trust data from out side your script, specailly from a user. All data should be escaped. All data should be data-type-verified with its type in the source (DB), so if user update his salary info, which has �float� data type in the DB, you should check for the posted data for the same type. All data should be data-size-verified with its size in the source (DB) as well.

    • Unit testing should be used.

    • Use templating languages (SMARTY-new release).

    • Use new cahing technologies (Smarty-cache, SQUID, Zend Platform, MEM Cache).

    • Each HTML-Form may be submitted to the same page, If the page has errors, user data should be filled in again.

    • Try to build Loosely Couplied Components (LCC), all components should be dependent as much as possible from each other, this will help you not to reinvint the wheel in the future.

    • �index.html� file should be replaced in all non php directories. This reduces the apache calls time to the non-indexed directories.

• Javascript Part:

  • Common error that you may use with JavaScript, is to link the HTML page to a lot of JavaScript files, this will lead to a huge number of requests. You can also use on-demand including for scripts, which means that you don’t include any JavaScript file unless you the functions inside it.

  • Also you have to check each JavaScript file size. Use gzip to reduce the file size. This usually gives you 70% less size than the regional one.

  • As well, if you have an Ajax form in your page, user may be able to submit this form more than once, which you don’t want to be happened. Disable all submit buttons after successfully submitting any form in order to disable �double submit�.

  • Too many white space in the files. this also enlarge the file too much.

  • Errors should be handled even in JavaScript. You can use the try{} catch{} directives to handle the errors. Users should not see any �JavaScript Error� in any page of your project.

  • No more alerts.

• QA & Testing Part:

  • Don’t test your hole project at once. You should test each package alone and approve it.

  • Every package should be tested alone. A portal testing should be applied later on.

  • No �Enhancements� should be added as a �bug�. It should be added as �Enhancement� option.

  • Install bug tracking system (e.g Bugzilla). It helps to keep track for all bugs and each bug life time as well.

  • Do a penetration test, performance test and stress test when deliver.

• Management, Planning and Deadlines Part:

  • Leaders should read the �Requirement Document� carefully in order to analyse it as much as possible in order to view the full picture.

  • Each developer should read his part of the �Requirement Document� carefully in order to view the full picture.

  • All functionalities should be splited to a small paces, listed, get priorities, describe the full details for each one and mark the top 20% features.

  • Plan our day, week and month. Each team member should have his �TO-DO� list for his day, week and even month if possible. This helps developer to manage his time carefully in order to close his task in and/or pre required deadline.

  • Team members should be self-motivated and should have the very high level of attendance by himself.

  • Each team member should sent a daily report to his leader, describes the tasks status for this day. As well, week report also should be sent in order to abstract what have been done through the week.

  • Create a �Deadline Delivery Status� Document. Update this document daily based, or at least twice a week.

  • Its a good idea to post a new �queue of the day� daily. Your team members will get a good feel daily, and they will start their every day with new strengths.

  • For any task you want to do, follow the following steps in order to solve it:

    • Give your self a time limit to solve any issue.

    • If you are stuck, try to find a different approach / algorithm / procedure.

    • If you are stuck, try to use a new techniques.

    • If you are stuck, ask for help. The best idea to do in this level is to say �I don’t know how to?�, but don’t waste any more time when you know that you’ll never do it alone.

  • It’ll be better to have a use-cases for all pages/ functionalities/ components and features.

  • You may split the developers into teams to compare the performance for each team. Note: you may also use a nicknames for developers.

  • Be positive, think positive.

• Source Control Part:

  • Use source version technology (e.g SVN). This will make sure that you have all your versions for your hole project, you can go back to any revision for any file at any time you need.

  • If you decide to (and you should) use a source versioning control system, I advise to do the following:

    • Use Tags, Branches and Trunks in order to have more than release. This helps to generate a version for QA, version for each update… etc.

    • Create a �SVN Tracking Document� in order to keep track for the versions and release that we are building with a brief description for each release.

    • ALL developers updates should be commented very very very well.

• Tools & Toys Part:

  • • We should have to set our tools list.

    • Each developer may have his own tools.

    • Use the tools as toys.

Waiting for your comments.