Project Management and all things workflow :)

I’ve recently been to Vienna, and visited local Austrian Startups Stammtisch. It went by the number #31, so quite a consistent event going on for more than a year now. The event took place in Sektor5 co-working space (which I have to recommend, because it’s a really cool place with only eur 18 per day! You can feel the international vibe and all that kinds of stuff).

Bureacracy. In order to open a traditional gmbh company, you may need to be patient and get a lot of papers and formalities. It can take up to 120 days.

Government support. However, the good side, is that the process of bureacracy is not that painful, as the govt. is on your side and supports businesses will to change the country to innovation-driven economy. Grant system is strong here (http://www.austrianstartups.com/grants/)

Hard to notice, when you’re from Russia, but Vienna is quite close to strongest european mainland startup hub: Berlin. An hour-flight only 🙂

English is embraced throughout the IT startups. So yaay!- Expats! However, you’re more welcomed, if you speak deutsch. And because socialistic mindset, a good Austrian professional is mostly more preferable, than a great expat 😉 And there are loads of cool pros in Austria.

Tons of sessions and meetups happen in Vienna, Salzburg and Graz. May keep you busy almost 100% of your time. There was a great atlassian event in Graz, that I wanted to attend, but didn’t. Sad.

Great startup (and established IT companies) scene! Some of the big startups from Austria include: Runtastic (surely you’ve heard about it), bikemap (great stuff, more route-oriented than strava), Shpock (my facebook is overloaded with it’s ads now), mySugr (basically an ecosystem of apps made for people with diabetes, by people with diabetes) and lots of others.

Vienna is extremely lovely!

Met great ppl from Austria, Ireland and Eastern Europe 😉

Hey to Odessa guys, who created a venture find and were searching for partners (Crop Inc),

I might be a captain obvious here, but supporting a process for an analyst / pm is a more important, than micromanaging tasks amongst developer pool.

When a new team member steps in, who’s responsibility is to manage development processes, she needs to find how to make business processes inside a company better.

Business processes are evaluated from various points of view, but in a nutshell, aside from developer professionalism, she needs to make sure there’s no room for slowdowns and uncertanties when product passes different stages across different teams. Whether there are delays in communication, or delays of resources for the project, or sick-days, – there should be a correct process to tackle such cases, in order to minimize negative outcome.

There’s always a temptation to micromanage issues, no matter how big the project is and how little time you have. But project manager’s job is to create a process that allows to handle various situations. Once the process has been established – keep an eye on the workflow, so that it doesn’t jump over the fence of how the process should work.

Fencing is the key idea. Micromanagement is bad, if you don’t have a clear process: it’s time consuming, it’s inefficient on a project scale (of course there are exceptions), and most important – micromanagement doesn’t cope with scaling.

So the typical steps to establish a working mechanism is to:

Create the process

Adjust it to keep all needed operations inside that process fence

Make sure operations can connect to each other via unified inputs and outputs

While working on Storia.me iPhone app, we’ve eventually came up to the three-week sprints. Empirically, they proved themselves to make product high quality and provided time to get moderate functionality chunks done. Two notes here:

First of all – this is does not include time for appStore approval. That’s additional week. So a release cycle is 1 month.

Second, we came to three-week sprints after we released MVP. Preparing the app for MVP was quite a kerfuffle, but we managed to finish needed bits in 2 months. Don’t forget to have some rest and go for a holiday after that 🙂

Time Distribution during 3 week sprint

2 weeks for development, 1 week for testing and fixing. Essential part of undistracted 2 weeks development, is to provide fully described User Stories with corner cases explained before the sprint. You also have to estimate all of the workload, and make sure it fits into the sprint. Leave tickets of a less priority on top of the backlog. Pay unprecedented attention to details, so that developer doesn’t need to waste time on communication and clarification (which always results in delays) how the described feature should work.

There are often times when stakeholders rush with some new request. For 80% of the time you’re (a good manager) able to protect developer and stories from scope creeps, but sometimes you are not able to do so. And here comes the last week of the sprint, that mostly handles such unfortunate situations.

Make sure that AppStore materials are ready one week before app submission. Screenshots for all resolutions and languages, descriptions for different markets, no legacy and unsupported SDKs.

Key point here is to make comfortable pace for the developer, so that as less things as possible distract him during the sprint. You know the rule: less distractions => more productivity.

And final achievement is predictable stable timely releases. These are something that are valued by stakeholders, investors, team and users.

Product is crafted by people. It is not a sum of collaborative work. It’s usually a combination of work, excitement, collaborative ideas, feedback loop inside the team throughout the whole project lifecycle.

Passion is right at the heart of every person, and if environment tends to motivate – a person will work hard to achieve a good result (appreciated by the team and himself). Moreover, working with passionate team amplifies the overall product, makes it bigger than sum of efforts.

I approach to motivation as to a three-factor equation.

Excitement about the project (and willingness to work on it)

Ability to apply your skills (and improve them)

Compensational part

Let’s leave out compensational part. Let’s also make a note, that such approach doesn’t work on lousy boring projects.

The rest two points are extremely transparent, if you work in a smaller companies with more or less ‘flat’ hierarchy and informal communication.

Excitement about the project comes from inspiration. It could be something cool, that brings value to the market. Aspirational team, that challenges you, while you challenge them. This makes it extremely easy to go & do your job day by day. Such teams later stick together, even working on different products, to exchange ideas and share experience (as we did with Ufa42 Conference).

Once the project is exciting, challenging – person starts to work hard in order to bring his valuable contribution. Developer, manager, designer, analyst – everyone is involved into general decisions, everyone is able to improve the product from the inside. Which means he can apply his skills in a good way, practice fresh approaches and technics, learn on mistakes, tune the workflow.

However, lack of involvement in product creation (aside from simply doing your job), vertical hierarchy and formal chain of command – it all kills the motivation. This brings us back to our equation: team is unhappy, not motivated = product not exciting. World doesn’t need boring products. Don’t forget: awesome pros won’t stick with something dull for a long time, they will leave as soon as they can. And we all know, that finding great teams is something almost impossible 🙂

Receive feedback on earlier stages, experiment with a limited set of users and influencers.

A scheme we came up with eventually, has three (four in special cases) versions before the final AppStore release. Each version is rolled out out for certain circle, with different readiness level.

Storia Alpha

Internal build for developers. After code is frozen, feature-complete version is sent to Preprod. Alpha version may be used as a proof-of-concept prototype, since it usually doesn’t require QA stage. Distributed via hockeyapp. Connected to dev server.

Storia Preprod

Quite often preprod version is tested together with design team, in order to see how well the mockup works in extreme cases.

Storia Beta

Stable version for early adopters. Helps in revealing bugs, inconsistencies and everything else that fell out of scope during previous stages, shows overall initial reception. Has a 1-week period for testing, before AppStore submission.

Version that is used by stakeholders, everyone in the company and users from countries, where Storia is not released yet. Distributed via hockeyapp. Connected to production server.

Why hockeyapp?

It is cross-platform, meaning that we can extrapolate iOS scheme to Android.

It shows new updates instantly, meaning we can be sure that most Beta users are using the latest version.

Bug fixing and merging

Fixes are merged into current version branch. If QA team finds a bug in Beta version – fixed are merged in Beta.

It is obvious, that we cannot hotfix an AppStore version =) Critical fixes are tested in Beta and issued as an AppStore update (depending on severity). Minor fixes are added to the next planned version.

Special cases, Storia Testflight

Testflight version is identical to Beta and the one submitted to AppStore. Connected to production server. We use it when we need to test a certain feature on production server privately. We needed to test video recording & processing on backend, but couldn’t rollout this features to Beta access (they could have produced a lot of broken content). Testflight Version was internally tested on production server by dev and QA teams, and proceeded to App Store once all obstacles were moved out of the way.

Q: Why to AppStore, and not to beta?

A: We rolled out video recording and playback features simultaneously for general public and Beta access).

Bug fixing for Testflight version sometimes involved rolling out the fix in Beta, since hockeyapp update takes a bit less time to process.

For the past 9 months, come hell or high water, this flow proved itself to be efficient and transparent. It took two sprints initially to get used to the scheme and tune it a bit. Release cycle is stable, updates work well, adopters get new features faster, team receives feedback earlier.

I would love to hear criticism, or get a fresh look at similar distribution process in your teams =)

Well-coordinated work across teams – let’s say design and development – is a huge deal when it comes to delivering a good product on time! So, part of my job as a project manager is making sure that the assets passed from design into development are ready for implementation.

At the very heart of the process, design review is nothing complex. You should know human interface guidelines, platform restrictions, requirements and a little bit of common sense =)

Here are the common issues I often face, when reviewing design:

Design does not incorporate all the details on features planned;

Navigation controls are used inappropriately from the native experience point of view; or simply not intuitive;

Assets are missing during delivery phase;

Mockup does not look good, when populated with real user data; mockup has not been stress-tested on extreme cases.

As our teams worked together, we optimized our process to minimize adverse effects on the points above.

1. Kick-off with an interview.

When the team is excited – it shines in willingness to collaborate on building a valuable product. Once an applicant to a designer position is excited – she starts to ask questions and share her ideas. I try to understand what the candidate thinks about the project, her motivation, her past projects experience: was there an established flow when this designer had been working on a product, how did the teams collaborate.

2. Help designer to understand the product, build solid requirements

There is a timeframe for a designer to get to know the product. Have materials prepared, older designs structured (for the retrospective view), corner cases described.

The whole team was pleasantly surprised when our new UX designer asked for requirements documents and stayed knee-deep in them for a couple of days. He came up with rational and neat optimization.

We describe global functional requirements in Confluence, with obstacles, corner cases and retrospectives added to the main article. This gives a designer (and practically any new person in the team) the understanding which issues and mistakes we faced, what are the bottlenecks of particular solutions, and why we currently have an effective solution if we already do.

We describe platform-specific flows and requirements in User Stories, which also work as checklists for designers.

The one thing I want to point at again, are the corner cases. They usually fall out of scope and do not apply to typical user behavior, but may result in unpleasant experience. We brief a designer on corner cases before he starts prototyping.

3. Create checklists for mockups

There is a quite popular problem companies face: real user data doesn’t play nicely with the mockup. The design may look gorgeous and trendy and flat, but once you start populating it with longer names, venues, low quality photos, vivid photos that make overlayed text unreadable – the whole greatness falls apart. What to do here?

Reflect min and max length for the fields in the requirements. This way designer knows what to expect from the real data.

Prepare corner case text examples, to check how well the mockup stands against them. For example, use location named ‘Venkata Narasimha Raju vari Bahadur’ instead of ‘Union Station’. Show how long text should be cut, if needed.

Keep in mind that if you support multiple languages, some buttons may require more space for a label to fit.

Text overlays. If text overlays a picture, be sure that text is still readable even on a bright vivid photograph.

4. Wording for mockups

Wording mistakes happen quite often. You may have ‘Done’ button in current application, and ‘Save’ in an updated mockup, or even different labels for the same action in different sections. I make sure wording is correct and synced across designs, before dev team starts implementing it. Easiest path is to have all metaphors documented inside a task-tracking or wiki-system, so that designer knows how to name each element properly. This saves a lot of time and nerve for everyone involved.

5. Standardize assets delivery

In order to be sure we got all the assets we need we created a small guide on design delivery in a form of simple folder structure.

This is a first article from “How to accurately estimate incoming projects” series, aimed to help you see the possible future pitfalls. This includes both outsourcing projects and the ones where different teams around the world are involved.IT industry is dynamic. Companies change APIs, IDEs, upgrade hosting servers software, raise new compatibility issues. Of course improvements are welcome, but there is no way you will have a perfect product once and forever – it needs to be re-iterated. Don’t forget about hundreds of different environments that the system should work on. And people.

1. Client Interaction Time

It’s not a big deal when we are talking about local business (and even in such close distance email response delay time could be significant and expensive), but when you’re dealing with international clients and partners, this becomes a more significant issue.

There are several simple rules that are wise to follow in order to keep up with the deadlines:

Don’t underestimate time needed for interaction;

Client won’t run and read your email instantly, he has work to do;

Response time could vary, but prepare for the worst.

Let’s look at an example: you are building an ecommerce website. The catalogues structure is a bit tricky so you need to clarify where a product recommendation slider leads.

You send the request;

Client reads it in 2 hours;

Gets back to you with some questions in order provide proper answer;

When you answer him – you are already off from work;

You read the final response the next day only.

Of course it’s not what may happen every time, but you need to take such issues into account before they happen. Here is what could cause “lags” on the client side as well:

Clarification from a third party (could be a hosting provider, lawyers, content providers, etc);

Interaction between departments;

Approval of department manager and other bureaucratic procedures.

In addition to that, there’s been quite a few times, when our clients from other countries needed to clarify detailed info with a a third-party with no people on that side speaking English at all.
The main point of this section is to make you understand how heavily client interaction lag can affect the entire project. It’s worth mentioning because these things rather frequently fall out of scope of attention.

How to avoid possible adverse effects? A checklist or a roadmap will be helpful to manage handling tasks in advance. In Codebranch, we prepare a project roadmap with Freeze dates, which are the last dates that a certain part of team-client interaction is due. For instance, there are:

Design Freeze Date – this is when the client takes a final approval and signoff to the proposed design, all the amendments and improvements to the design have to go before that date.

Functionality Freeze Date – the milestone by which the final application functionality should be agreed upon.

Content Delivery Date – this is when the content provided by client is due, so the client would know the timing in advance and have enough time to gather the content.

Hosting or CDN accounts purchase dates, domain name registration deadline – when, and no later, the accounts need to be available to the development team in order to set the environment up and deploy on time.

These dates are elaborated together with the client, basing on the delivery timelines that the client suggests, and adjusted accoring to the internal development milestones. This approach helps both the team and the client meet the responsibilities in working on a web project, and contributes into building a good working relationship.