How we work?

We approach each engagement with an optimistic, calm, step-by-step approach that breaks problems down into manageable component parts. We start by working closely with you and your team to fully understand and articulate the business need you are trying to address. We then apply reliable and proven best-practice methodologies to achieve consistent and repeatable results.

Whether working with client-provided processes, or with our own methodology, we can always modify our techniques to suit each unique client situation, and in many cases, we can even leave our methods behind, where the infrastructure we’ve helped create can produce predictable and scalable results into the future.

Project predictability

Our main goal is to increase project predictability - i.e. planning and following the plan. Without this you can't be sure that where is your project right now, without this you may spend a lot of money and you will even do not know how much money you need to pay till you get something really working

We understand that for any project success there should be clearly specified project goals and project success criteria. The same is true for any project iteration.

We understand that in most cases more tracking means more time spent and more costly project, so we always try to define process that will be optimal for particular project, i.e. not required to spend lot of time when it is not absolutely required, but is enough for understanding where we are and what will be next.


We understand that:

  • Quality assurance (QA) is one of the most important parts of any project to be successful.
  • QA is complex methodology that should be included into any part of project process - including development, documenting.
  • As early issue will be found as cheaper fix it.


We understand that in software development excellent knowledge of specific technology, and we are constantly performing trainings with our stuff.

Main points of SweetSoft development policy

  • Design review - any project architecture must be reviewed before coding.
  • Checkin code review - any code written and committed to the trunk (main code branch) must be reviewed before committing.
  • Checkin review for project documentation - any document writen must be reviewed before publishing
  • Management review - any project should pass weekly management review to be sure that project managed correctly.
  • Project status tracking - any project should have weekly report that summarize project results and issues.

Internal process framework

We have worked with different clients and many of them have their own set of tracking tools. Anyway our process framework can easy be adopted to any set of set of tracking tools.

Here is the list of fundamental blocks we use:

  • Microsoft SharePoint server (MOSS) – for tracking project documentation, tasks, calendar & dates (milestones), risk tracking, communication plan (including info about team and responsibility of each team member)
  • Daily/weekly reports for either individual team member or whole project – are tracked on MOSS using InfoPath templates and/or via email.
  • Issue & Source tracking systems
  • Each of our project pass internal Weekly Management Review – to make sure that Team Lead or Project Manager did not miss something from management point of view
  • Periodical (2-4 weeks) external to the project code review – deep review performed by Sr. developers who do not work on the project – to be sure that team was not missed something critical (sometime team may work under some assumptions that can affect project, but can’t be found in quick checkin review.).