Watch the Experts Zone podcast with Cezary Lewczuk about how to bring your project on the requirements stage to success. Cezary - the Project Manager at Frontend House - will share management practices that will help your project to prosper.
Experts Zone is the place where our professionals deliver the precious experience in design, development, project management and other fields. Concrete and useful information for you from your Frontend House experts.
In today’s Experts Zone #2 episode - Management Practices to Bring Your Project to Success - you will find:
- 00:00 - Intro
- 00:45 - Six factors to successful project. Definition of success
- 02:11 - Project Life Cycle
- 03:15 - Scoping. Defining the scope
- 04:11 - Application for installers. Check also: iotoak.com
- 05:09 - Roadmaps
- 06:40 - Statement of work
Transcription
Hi, guys, my name is Cezary Lewczuk and I work as a project manager at Fronted House. My job starts by collecting the requirements for your project. I also work at presale and make sure that the whole process is right. I choose the methodology with the client and obviously with our developers. My job consists of collecting the requirements, like I said, and making sure that they are delivered at the right time and the right scope. If you want to check out more about me and my job, check out this episode of the Frontend House Expert Zone.
Six factors to successful project
One of the main goals of project managers, scrum masters is to bring the project to this goal. A good start is to define the definition of success, which I would like to discuss today with you. On the screen now, you can see the old definition of the project success because it comes from the Project Manager Journal published in 1988. Looking at the points contained in it, we can come to a simple conclusion: defining the time of implementation, scope of work, budget, target groups and clear business goals in a straight line leads to the satisfaction of the sponsor of the project and at the same time its happy ending, quite timeless, right?
Right now, let's look on the other side of the coin. In 2017, Project Manager Institute conducted a survey which asked three thousand project managers: “Why did your project fail?”. Let's look at the top reasoning: changing organization priorities, inaccurate requirements, gathering, changing project objectives, inadequate vision or goal for the project. The element that links the definition of success to the survey is the impact business requirements on the overall implementation of the project. They say there is no wrong way to collect the requirements other than not collecting them at all.
Project Life Cycle
And the image you probably know well: the basic life cycle of the project. From my experience in many software houses, startup and corporate cultures, there is a clearly defined boundary between the work of a business and development team - statement of work. The document I would like to focus on today is a kind of an answer to this distinction. Project initiation through the eyes of a project manager or scrum master often begins when the project is handed over to them for the implementation.
To show the emphasis of this element, I would like to place us before the project initiation stage in example, delivery for development. As a business owner of an idea, the concept turns to the company, implementing the product, or as the person responsible for business development at such an early stage of the project’s life. To prepare properly to collect the right requirements, you should focus on the first step to prepare the statement work - collecting the requirements.
Scoping. Defining the scope
And the scoping stage is a good thing for the technical person, possibly the person who will act as the technical leader of the project and a person responsible for the implementation time, team composition, methodology and project management. Imagine an ordinary doc file. We put in the basic information that we know about the project in a similar way to the Project Charter, along with an explanation of the keywords, technical names using the project. Remember, to keep this product alive. At the scoping stage it is good to involve a technical person, possibly a person who will act as the technical leader of it.
And the second person is someone responsible for the implementation time team composition, methodology, project management in general. Information during the implementation will flow through various channels. It is important that the person responsible for it takes care of it up to the status.
The next step is to break the application down to distinctly different components.
Application for installers
Here is an example set of questions that I have prepared for our Smart Energy Control project. If you want to know more about it, check the link here. Thanks to the answers to questions such as what is that supposed to do? Who is the default user? How do we want to distribute the application? And do we want to store any data if we want to, then where and how we secure it? Thanks to these answers, we learned that the users only use Android systems in our case scenario, as our target user, we don't need to publish an application for him into the Google store.
We don't have to write support for IOS devices. The result of discussion with the client should be prepared functional requirements, which form a solid background for starting the development process as milestones or epics. Remember to develop this document also during development.
Roadmap
Now, in order to meet the client's needs, which is obviously the implementation of the project within a certain time, a roadmap should be included in this document. The key element in crafting it, it is cooperation with the client in prioritizing and defining key functionalities. When placing them on the roadmap, which I encourage you to come back during the demo, release, status meeting. Remember to specify the approximate date of the implementation or the order of delivery.
Each of the milestones should have a supervisor. Remember that the project is not only development, but is also graphic, marketing work, copywriting, etc. Can such a document be used in an agile process? Obviously, in Scrum you can use it to create an epics, in Waterfall you can use it to create milestones or even prioritize the order of your epic etc. Here, let me show you the programs I used to use to create such a document.
First one is craft.io. It’s quite helpful in the first stage when you cooperate a lot with the client, there is not much internal work here. It's just a back-and-forth communication and to show the quick ways and the quick view of how we want to deliver their milestones or the requirements. On the other hand, to move the job forward, I use to work on Smartsheets, like you see here. Or even Microsoft projects, which is helpful because the gant is pretty cool.
Statement of work
All this information should consider the attachment to the contract with the client and form the basis of requirements in the project. I recommend placing a breakdown of the release planner, for example, you can split it to the alpha, beta, final release. Remember to include the payment information also. General, this creates additional value for the client because the document prepared in this way can be used anyway by the client. And it's a part which is independent from development. While for business, this creates a basis on which the scope of the project will be settled. And what is most important, what will not be delivered. Obviously, this is just a short general treatment of the topic. What's your way of collecting the requirements? Please let me know in the comments. My name is Cezary Lewczuk, I’m project manager at frontendhouse.com. And I hope to hear from you again soon.
